Creación de Máquinas Virtuales en Azure

Contents
Documentación sobre máquinas virtuales Windows

Información general
Acerca de Virtual Machines
Guías de inicio rápido
Creación de una máquina virtual: Azure Portal
Creación de una máquina virtual: PowerShell
Creación de una máquina virtual: CLI de Azure
Tutoriales
1 - Creación y administración de una máquina virtual
2 - Creación y administración de discos
3 - Automatización de la configuración
4 - Creación de imágenes de máquina virtual
5 - Máquinas virtuales de alta disponibilidad
6 - Creación de un conjunto de escalado
7 - Equilibrio de carga de máquinas virtuales
8 - Administración de redes
9 - Copia de seguridad de máquinas virtuales
10 - Control de máquinas virtuales
11 - Seguimiento y actualización de máquinas virtuales
12 - Supervisión de máquinas virtuales
13 - Administración de la seguridad de máquinas virtuales
14 - Instalación de una pila de SQL\IIS\.NET
15 - Seguridad de servidores web con SSL
Ejemplos
Índice de PowerShell
PowerShell
Crear
Rápido
Máquina virtual completamente configurada
Máquina virtual de alta disponibilidad
Ejemplo de script personalizado
Uso de DSC
Máquina virtual a partir de carga de VHD
Conexión de un disco de sistema operativo
Máquina virtual a partir de instantánea
Administración del almacenamiento
Creación de un disco administrado a partir de un VHD
Creación de un disco administrado a partir de una instantánea
Copia de un disco administrado
Exportación de una instantánea como VHD a una cuenta de almacenamiento
Exportación del disco duro virtual de un disco administrado a una cuenta de
almacenamiento
Creación de una instantánea a partir de un disco duro virtual
Copia de una instantánea
Seguridad
Cifrado de una máquina virtual y sus discos de datos
Supervisión
Azure Monitor
Recopilación de detalles sobre todas las máquinas virtuales de una suscripción
Índice de la CLI de Azure
CLI
Crear
Rápido
Máquina virtual completamente configurada
Máquina virtual de alta disponibilidad
Ejemplo de script personalizado
Uso de la configuración de DSC
Creación de un disco administrado desde un disco duro virtual
Exportación de una instantánea como un disco duro virtual a una cuenta de
almacenamiento
Exportación del disco duro virtual de un disco administrado a una cuenta de
almacenamiento
Copia de una instantánea
Red
Protección del tráfico de red entre máquinas virtuales
Seguridad
Cifrado de una máquina virtual y discos de datos
Supervisión
Azure Monitor
Conceptos
Azure Resource Manager
Regions
Disponibilidad y rendimiento
Disponibilidad
Colocalización
Rendimiento de la red
Tamaños y tipos de máquinas virtuales
Máquinas virtuales de segunda generación
Uso general
Ampliables de la serie B
Proceso optimizado
Memoria optimizada
VCPU restringidas
Almacenamiento optimizado
Optimización del rendimiento
Proceso acelerado
GPU optimizada
Configuración de los controladores de GPU
Informática de alto rendimiento
Generaciones anteriores
Tamaños aislados
Unidades de proceso de Azure (ACU)
Puntuaciones de pruebas comparativas
Cuotas de vCPU
Instancias reservadas
Pago de máquinas virtuales por adelantado
¿Qué son las reservas de Azure?
Flexibilidad de tamaño de instancia de máquina virtual
Hosts dedicados
Mantenimiento y actualizaciones
Almacenamiento en disco
Introducción a los discos administrados
Selección de un tipo de disco para máquinas virtuales de IaaS
Cifrado
Diseño para alto rendimiento
Seguridad de disco
Objetivos de escalabilidad para discos
Copia de seguridad y recuperación ante desastres para discos
Discos de sistema operativo efímero
Redes
Conjuntos de escalado
Automatización de la infraestructura
Seguridad
Seguridad y directivas
Azure Disk Encryption
Controles de seguridad integrados
Estados y ciclo de vida
Supervisión
Copia de seguridad y recuperación
Ejemplo de infraestructura
Guías de procedimientos
Creación de máquinas virtuales
Uso de hosts dedicados
PowerShell
Portal
Uso de C#
Uso de un disco especializado
Portal
PowerShell
Uso de una plantilla con C#
Creación de una máquina virtual con Chef
Uso de Java
Uso de Python
Uso de una plantilla
Conexión a una máquina virtual
Uso de la licencia para la ventaja de uso híbrido de Azure
Uso de los derechos de hospedaje multiinquilino para Windows 10
Seguridad de máquinas virtuales
Recomendaciones
Acceso Just-In-Time
Cifrado
Escenarios para el cifrado de discos en Windows
Cifrado de máquina virtual con la CLI de Azure
Cifrado de máquina virtual con Azure PowerShell
Cifrado de máquina virtual con Azure Portal
Almacén de claves de Azure Disk Encryption
Scripts de ejemplo de cifrado de discos
Solución de problemas del cifrado de discos
Preguntas frecuentes sobre el cifrado de discos
Cifrado de discos: versión anterior (AAD)
Almacén de claves de Azure Disk Encryption
Escenarios para el cifrado de discos en Windows
Uso de WinRM
Uso de controles de acceso
Uso de directivas
Creación de un almacén de claves
Protección de máquinas virtuales
Copia de seguridad de máquinas virtuales
Copia de seguridad de una sola máquina virtual
Copia de seguridad de varias máquinas virtuales
Restauración de un disco
Restauración de archivos individuales
Configuración de la recuperación ante desastres para máquinas virtuales
Habilitar la recuperación ante desastres para una máquina virtual
Obtención de detalles de recuperación ante desastres para una máquina virtual
Conmutación por error de una máquina virtual en otra región
Administración de máquinas virtuales
Uso de máquinas virtuales
Tareas comunes de PowerShell
Cambio del tamaño de máquina virtual
Intercambio del disco del SO
Etiquetado de una máquina virtual
Sincronización de hora
Ejecución de scripts en una máquina virtual
Custom Script Extension
Ejecución de comando
Cambio de la letra de unidad temporal
Cambio del conjunto de disponibilidad
Descarga de una plantilla
Agente de máquina virtual de Azure
Mitigación de ejecución especulativa
Supervisión de metadatos
Habilitar virtualización anidada
Mantenimiento de la plataforma
Notificaciones de mantenimiento
CLI
Portal
PowerShell
Control de mantenimiento
CLI
Eventos programados
Servicio de eventos programados de Windows
Supervisión de máquinas virtuales
Azure Monitor para máquinas virtuales
Creación de alertas de métrica
Crear alertas del registro
Uso de imágenes
Imágenes compartidas
PowerShell
Portal
CLI
Registro de aplicaciones para uso compartido
Solución de problemas de imágenes compartidas
Generador de imágenes (versión preliminar)
Uso de CLI de Azure
Compilación para galerías de imágenes
Actualización de una imagen existente
Almacenamiento de scripts
Referencia de plantilla
Solución de problemas
Búsqueda y uso de imágenes
Preparación de la máquina virtual para la carga
Captura de una máquina virtual en una imagen
Uso de una imagen generalizada
Creación de una imagen con Packer
Uso de imágenes de cliente de Windows
Descarga de disco existente
Disponibilidad y escala
Virtual Machine Scale Sets
Alta disponibilidad
Creación de un grupo de selección de ubicación por proximidad
Portal
PowerShell
Escalado vertical
PowerShell
Portal
Uso de herramientas de automatización
Chef
Publicación de aplicación web desde Visual Studio
Ejecución de aplicaciones
SQL Server
MongoDB
SAP en Azure
Clúster MATLAB
Visual Studio
Informática de alto rendimiento (HPC)
Clúster de HPC Pack 2016
Integración de HPC Pack 2016 Azure Active Directory
Nodo principal de HPC Pack 2012 R2
Envío de trabajos locales a HPC Pack 2012 R2
Excel en HPC Pack
Agregar un disco
Azure PowerShell
Azure Portal
Desconexión de un disco
Implementación de discos con plantilla
Cargar un disco duro virtual en un disco: PowerShell
Cambio del tamaño de un disco
Uso del Explorador de Storage para administrar discos
Instantánea de un disco
Creación de una instantánea incremental
Copia de seguridad de discos no administrados
Migración y conversión
Conversión de disco entre Estándar y Premium
Migración a Premium Storage con Azure Site Recovery
Migración a Managed Disks
Máquina virtual no administrada en Managed Disks
Rendimiento
Habilitar el acelerador de escritura
Uso de Ultra Disks
Realización de pruebas comparativas de un disco
Búsqueda de discos sin conectar
Uso de File Storage
Preguntas más frecuentes de discos
Administración de redes
Creación de una red virtual
Apertura de puertos a una máquina virtual
Portal de Azure
Azure PowerShell
Asignación de direcciones IP públicas
Uso de varias NIC
Uso de redes aceleradas
Asignación de nombres DNS públicos
Resolución DNS
Configuración de identidades administradas
Portal
CLI
PowerShell
Plantilla de Azure Resource Manager
REST
SDK de Azure
Uso de extensiones de máquinas virtuales
Traslado y migración de máquinas virtuales
Cambio de suscripción o grupo de recursos
Traslado de regiones
Traslado a una zona de disponibilidad
Migración de máquinas virtuales de AWS y locales
Carga de máquina virtual local
De Amazon Web Services (AWS)
Uso de Azure Site Recovery
Migración del modelo clásico a Azure Resource Manager
Análisis a fondo de la migración
Planear la migración
Migrar mediante PowerShell
Errores comunes en la migración
Herramientas de la comunidad para la migración
Preguntas más frecuentes
Referencia
CLI de Azure
Azure PowerShell
.NET
Java
Node.js
Python
REST de Compute
REST de Managed Disks
Plantilla de Resource Manager
Recursos
Creación de plantillas
Desarrollo de aptitudes con Microsoft Learn
Azure Roadmap
Plantillas de la comunidad
Precios
Disponibilidad regional
Stack Overflow
Vídeos
Información general sobre las máquinas virtuales
Windows en Azure
27/11/2019 • 17 minutes to read • Edit Online
Azure Virtual Machines (VM ) es uno de los diversos tipos de recursos informáticos a petición y escalables que
ofrece Azure. Por lo general, elegirá una máquina virtual cuando necesite más control sobre su entorno
informático del que ofrecen las otras opciones. En este artículo se proporciona información sobre lo que debe
considerar antes de crear una máquina virtual, cómo crearla y cómo administrarla.
Una máquina virtual de Azure le ofrece la flexibilidad de la virtualización sin necesidad de adquirir y mantener el
hardware físico que la ejecuta. Sin embargo, aún necesita mantener la máquina virtual con tareas como
configurar, aplicar revisiones e instalar el software que se ejecuta en ella.
Las máquinas virtuales de Azure se pueden usar de diversas maneras. A continuación, se indican algunos
ejemplos:
Desarrollo y pruebas: las máquinas virtuales de Azure ofrecen una manera rápida y sencilla de crear un
equipo con configuraciones específicas necesarias para codificar y probar una aplicación.
Aplicaciones en la nube: como la demanda de la aplicación puede fluctuar, tendría sentido desde el punto de
vista económico ejecutarla en una máquina virtual en Azure. Paga por las máquinas virtuales adicionales
cuando las necesite y las desactiva cuando ya no sean necesarias.
Centro de datos ampliado: las máquinas virtuales de una red virtual de Azure se pueden conectar fácilmente
a la red de su organización.
El número de máquinas virtuales usadas por su aplicación se puede escalar vertical y horizontalmente a la cifra
necesaria para satisfacer sus necesidades.
¿Qué hay que considerar antes de crear una máquina virtual?

Siempre hay gran cantidad de consideraciones de diseño cuando se crea una infraestructura de aplicaciones en
Azure. Es importante pensar en estos aspectos de una máquina virtual antes de empezar:
Los nombres de los recursos de la aplicación
La ubicación donde se almacenan los recursos
El tamaño de la máquina virtual
El número máximo de máquinas virtuales que se pueden crear
El sistema operativo que ejecuta la máquina virtual
La configuración de la máquina virtual después de iniciarse
Los recursos relacionados que necesita la máquina virtual
Nomenclatura
Una máquina virtual tiene un nombre asignado y un nombre de equipo configurado como parte del sistema
operativo. El nombre de una máquina virtual puede tener hasta 15 caracteres.
Si usa Azure para crear el disco de sistema operativo, el nombre del equipo y el nombre de la máquina virtual son
iguales. Si carga y usa su propia imagen que contenga un sistema operativo ya configurado y la usa para crear
una máquina virtual, los nombres pueden ser diferentes. Se recomienda que, cuando cargue su propio archivo de
imagen, haga que el nombre del equipo en el sistema operativo y el nombre de la máquina virtual sean iguales.
Ubicaciones
Todos los recursos creados en Azure se distribuyen entre diversas regiones geográficas de todo el mundo. Por lo
general, se llama a la región ubicación cuando se crea una máquina virtual. Para una máquina virtual, la
ubicación especifica dónde se almacenan los discos duros virtuales.
En esta tabla se muestran algunas de las formas en que puede obtener una lista de ubicaciones disponibles.
MÉTODO DESCRIPCIÓN
Portal de Azure Seleccione una ubicación en la lista cuando cree una máquina
virtual.
Azure PowerShell Use el comando Get-AzLocation.
API DE REST Use la operación para mostrar la lista de ubicaciones.
CLI de Azure Use la operaciónaz account list-locations.
Tamaño de VM
El tamaño de la máquina virtual que use depende de la carga de trabajo que vaya a ejecutar. El tamaño que elija
determina factores tales como la capacidad de almacenamiento, la memoria y la capacidad de procesamiento.
Azure ofrece una amplia variedad de tamaños para admitir muchos tipos de usos.
Azure cobra un precio por hora en función del tamaño y el sistema operativo de la máquina virtual. Para las
fracciones de hora, solo cobra los minutos usados. El precio del almacenamiento se calcula y se cobra por
separado.
Límites de máquina virtual
Su suscripción tiene límites de cuota predeterminados que pueden afectar a la implementación de numerosas
máquinas virtuales en su proyecto. El límite actual por suscripción es 20 máquinas virtuales por región. Para
aumentar estos límites, cree una incidencia de soporte técnico y solicite un aumento
Imágenes y discos del sistema operativo
Las máquinas virtuales usan discos duros virtuales (VHD ) para almacenar el sistema operativo y los datos. Estos
discos también se usan para las imágenes entre las que se puede elegir para instalar un sistema operativo.
Azure proporciona muchas imágenes de Marketplace que se pueden usar con diversas versiones y tipos de
sistemas operativos Windows Server. Las imágenes de Marketplace se identifican mediante el publicador de la
imagen, la oferta, la SKU y la versión (normalmente, la versión se especifica como la más reciente). Solo se
admiten los sistemas operativos de 64 bits. Para más información sobre los sistemas operativos invitados
admitidos, roles y características, consulte Soporte de software de servidor de Microsoft para las máquinas
virtuales de Microsoft Azure.
En esta tabla se muestran algunas maneras de encontrar la información sobre una imagen.
Portal de Azure Los valores se especifican automáticamente cuando se

selecciona una imagen para usarla.
Azure PowerShell Get-AzVMImagePublisher -Location location

Get-AzVMImageOffer -Location location -Publisher
publisherName
Get-AzVMImageSku -Location location -Publisher
publisherName -Offer offerName
API de REST List image publishers (Lista de publicadores de imágenes)

List image offers (Lista de ofertas de imágenes)
List image skus (Lista de SKU de imágenes)
CLI de Azure az vm image list-publishers --location ubicación

az vm image list-offers --location location --publisher
publisherName
az vm image list-skus --location location --publisher
publisherName --offer offerName
Puede elegir cargar y usar su propia imagen y, cuando lo haga, no se usan el nombre del publicador, la oferta ni la
SKU.
Extensiones
Las extensiones de máquina virtual ofrecen funcionalidades adicionales de máquina virtual por medio de la
configuración posterior a la implementación y tareas automatizadas.
Pueden llevarse a cabo estas tareas comunes mediante las extensiones:
Ejecutar scripts personalizados: la extensión de script personalizado ayuda a configurar cargas de trabajo en
la máquina virtual al ejecutar su script cuando se aprovisiona la máquina virtual.
Implementar y administrar configuraciones: la extensión de configuración de estado deseado (DSC ) de
PowerShell ayuda a configurar DSC en una máquina virtual para administrar entornos y configuraciones.
Recopilar datos de diagnóstico: la extensión Diagnósticos de Azure ayuda a configurar la máquina virtual
para que recopile datos de diagnóstico que sirvan para supervisar el estado de la aplicación.
Recursos relacionados
Los recursos de esta tabla se usan en la máquina virtual y deben ya existir o crearse al tiempo que la máquina
virtual.
RESOURCE OBLIGATORIO DESCRIPCIÓN
Grupos de recursos Sí La máquina virtual debe encontrarse en

un grupo de recursos.
Cuenta de almacenamiento Sí La máquina virtual necesita la cuenta

de almacenamiento para almacenar sus
discos duros virtuales.
Red virtual Sí La máquina virtual debe ser miembro

de una red virtual.
Dirección IP pública Sin La máquina virtual puede tener una

dirección IP pública asignada para
acceder remotamente a ella.
Interfaz de red Sí La máquina virtual necesita la interfaz

de red para comunicarse en la red.
Discos de datos Sin La máquina virtual puede incluir discos

de datos para ampliar las
funcionalidades de almacenamiento.
¿Cómo se crea la primera máquina virtual?
Hay varias opciones para crear la máquina virtual. La decisión que tome depende del entorno en que se
encuentre.
En esta tabla se proporciona información para comenzar a crear la máquina virtual.
MÉTODO ARTÍCULO
Portal de Azure Creación de una máquina virtual que ejecuta Windows en el

portal
Plantillas Creación de una máquina virtual Windows con una plantilla

del Administrador de recursos
Azure PowerShell Creación de una máquina virtual Windows con PowerShell
SDK de cliente Implementación de recursos de Azure mediante C#
API de REST Create or update a VM (Creación o actualización de una

máquina virtual)
CLI de Azure Creación de una máquina virtual con la CLI de Azure
Aunque se espera que nunca suceda, en ocasiones algo sale mal. Si se ve en esta situación, consulte la
información en Solución de problemas de implementación de Resource Manager con la creación de una máquina
virtual Windows en Azure.
¿Cómo administro la máquina virtual que he creado?

Las máquinas virtuales pueden administrarse mediante un portal basado en el explorador, herramientas de línea
de comandos con compatibilidad para scripts o directamente a través de API. Algunas tareas de administración
habituales que puede realizar es obtener información sobre una máquina virtual, iniciar sesión en una máquina
virtual, administrar la disponibilidad y realizar copias de seguridad.
Obtención información acerca de una máquina virtual
En esta tabla se muestran algunas maneras en que puede obtener información sobre una máquina virtual.
Portal de Azure En el menú central, haga clic en Máquinas virtuales y

seleccione la máquina virtual en la lista. En la hoja de la
máquina virtual, puede ver información general, establecer
valores y supervisar métricas.
Azure PowerShell Para información sobre cómo usar PowerShell para

administrar máquinas virtuales, consulte Creación y
administración de máquinas virtuales Windows con el módulo
de Azure PowerShell.
API DE REST Use la operación para obtener información sobre la máquina

virtual para conseguir información acerca de una máquina
virtual.
SDK de cliente Para información sobre cómo usar C# para administrar

máquinas virtuales, consulte Administración de Azure Virtual
Machines con Azure Resource Manager y C#.
CLI de Azure Para información acerca del uso de la CLI de Azure para
administrar las máquinas virtuales, consulte la referencia de la
CLI de Azure.
Inicio de sesión en la máquina virtual

Use el botón Conectar en Azure Portal para iniciar una sesión de Escritorio remoto (RDP ). En ocasiones, algo sale
mal cuando se intenta usar una conexión remota. Si se ve en esta situación, consulte la información de ayuda en
Solución de problemas de conexiones del Escritorio remoto a una máquina virtual de Azure con Windows.
Administración de la disponibilidad
Es importante que comprenda cómo garantizar una alta disponibilidad para la aplicación. Esta configuración
supone crear varias máquinas virtuales para asegurarse de que haya al menos una ejecutándose.
Para que su implementación pueda optar a nuestro SLA de máquina virtual 99,95, debe implementar dos o más
máquinas virtuales que ejecuten la carga de trabajo dentro de un conjunto de disponibilidad. Esta configuración
garantiza que las máquinas virtuales estén distribuidas entre varios dominios de error e implementadas en hosts
con diferentes períodos de mantenimiento. En el SLA de Azure completo se explica la disponibilidad garantizada
de Azure como un conjunto.
Copia de seguridad de la máquina virtual
Un almacén de Recovery Services se usa para proteger datos y recursos en los servicios Azure Backup y Azure
Site Recovery. Puede usar un almacén de Recovery Services para implementar y administrar copias de seguridad
para máquinas virtuales implementadas con Resource Manager mediante PowerShell.
Pasos siguientes
Si tiene intención de trabajar con máquinas virtuales Linux, consulte Azure y Linux.
Conozca las directrices para configurar la infraestructura en el Tutorial de la infraestructura de Azure de
ejemplo.
Inicio rápido: Creación de una máquina virtual de
Windows en Azure Portal
Las máquinas virtuales de Azure pueden crearse mediante Azure Portal. Este método proporciona una interfaz
de usuario basada en explorador para crear máquinas virtuales y sus recursos asociados. En esta guía de inicio
rápido se muestra cómo usar Azure Portal para implementar una máquina virtual (VM ) en Azure que ejecuta
Windows Server 2019. Para ver la máquina virtual en acción, conéctese a la máquina virtual mediante RDP e
instale al servidor web IIS.
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.
Inicio de sesión en Azure

Inicie sesión en Azure Portal en https://portal.azure.com.
Crear máquina virtual

1. Escriba máquinas virtuales en la búsqueda.
2. En Servicios, seleccione Máquinas virtuales.
3. En la página Máquinas virtuales, seleccione Agregar.
4. En la pestaña Aspectos básicos, en Detalles del proyecto, asegúrese de que esté seleccionada la
suscripción correcta y luego elija Crear nuevo grupo de recursos. Escriba myResourceGroup para el
nombre.
5. En Detalles de instancia, escriba myVM en Nombre de máquina virtual y elija Este de EE. UU. como
Región. Después, seleccione Windows Server 2019 Datacenter para la Imagen. Deje los demás valores
predeterminados.
6. En Cuenta de administrador, proporcione un nombre de usuario, como azureuser, y una contraseña. La
contraseña debe tener al menos 12 caracteres de largo y cumplir con los requisitos de complejidad
definidos.
7. En Reglas de puerto de entrada, elija Permitir los puertos seleccionados y luego seleccione RDP
(3389) y HTTP (80) en la lista desplegable.
8. Deje los valores predeterminados restantes y luego seleccione el botón Revisar + crear en la parte
inferior de la página.
Conexión a la máquina virtual

Cree una conexión a Escritorio remoto en la máquina virtual. Estas instrucciones indican cómo conectarse a la
máquina virtual desde un equipo Windows. En un equipo Mac, necesita un cliente RDP como este Cliente de
Escritorio remoto de Mac App Store.
1. Haga clic en el botón Conectar en la página de información general de la máquina virtual.
2. En la página Conectarse a una máquina virtual, mantenga las opciones predeterminadas para
conectarse por dirección IP a través del puerto 3389 y haga clic en Descargar archivo RDP.
3. Abra el archivo RDP que descargó y haga clic en Conectar cuando se le solicite.
4. En la ventana Seguridad de Windows, seleccione Más opciones y, después, Usar otra cuenta. Escriba
el nombre de usuario como localhost\username, escriba la contraseña que creó para la máquina virtual y
luego haga clic en Aceptar.
5. Puede recibir una advertencia de certificado durante el proceso de inicio de sesión. Haga clic en Sí o en
Continuar para crear la conexión.
Instalación del servidor web

Para ver la máquina virtual en acción, instale el servidor web IIS. Abra un símbolo del sistema de PowerShell en
la máquina virtual y ejecute el siguiente comando:
Install-WindowsFeature -name Web-Server -IncludeManagementTools
Cuando haya terminado, cierre la conexión RDP con la máquina virtual.
Página principal de IIS

En el portal, seleccione la maquina virtual y, en su información general, utilice el botón Haga clic para copiar a
la derecha de la dirección IP para copiarla y pegarla en una pestaña del explorador. Se abrirá la página de
bienvenida de IIS predeterminada, y debería tener el siguiente aspecto:
Limpieza de recursos
Cuando ya no los necesite, puede eliminar el grupo de recursos, la máquina virtual y todos los recursos
relacionados.
Seleccione el grupo de recursos de la máquina virtual y haga clic en Eliminar. Confirme el nombre del grupo de
recursos para terminar de eliminar los recursos.
Pasos siguientes
En esta guía de inicio rápido, ha implementado una máquina virtual sencilla, ha abierto un puerto de red para el
tráfico web y ha instalado un servidor web básico. Para más información acerca de las máquinas virtuales de
Azure, continúe con el tutorial de máquinas virtuales Windows.
Tutoriales de máquinas virtuales Windows de Azure
Inicio rápido: Creación de una máquina virtual
Windows en Azure con PowerShell
El módulo de Azure PowerShell se usa para crear y administrar recursos de Azure desde la línea de comandos de
PowerShell o en scripts. En esta guía de inicio rápido se muestra cómo usar el módulo de Azure PowerShell para
implementar una máquina virtual de Azure que ejecuta Windows Server 2016. Para mostrar la máquina virtual
en acción, también se conectará a la máquina virtual mediante RDP e instalará el servidor web IIS.
Inicio de Azure Cloud Shell

Azure Cloud Shell es un shell interactivo gratuito que puede usar para ejecutar los pasos de este artículo. Tiene
las herramientas comunes de Azure preinstaladas y configuradas para usarlas en la cuenta.
Para abrir Cloud Shell, seleccione Pruébelo en la esquina superior derecha de un bloque de código. También
puede ir a https://shell.azure.com/powershell para iniciar Cloud Shell en una pestaña independiente del
explorador. Seleccione Copiar para copiar los bloques de código, péguelos en Cloud Shell y, luego, presione
Entrar para ejecutarlos.
Creación de un grupo de recursos

Cree un grupo de recursos de Azure con New -AzResourceGroup. Un grupo de recursos es un contenedor lógico
en el que se implementan y se administran los recursos de Azure.
New-AzResourceGroup -Name myResourceGroup -Location EastUS

Cree una máquina virtual con New -AzVM. Proporcione nombres para cada uno de los recursos y el cmdlet
New-AzVM los creará si aún no existen.
Cuando se le solicite, proporcione un nombre de usuario y una contraseña que se usarán como credenciales de
inicio de sesión para la máquina virtual:
New-AzVm `
-ResourceGroupName "myResourceGroup" `
-Name "myVM" `
-Location "East US" `
-VirtualNetworkName "myVnet" `
-SubnetName "mySubnet" `
-SecurityGroupName "myNetworkSecurityGroup" `
-PublicIpAddressName "myPublicIpAddress" `
-OpenPorts 80,3389

Finalizada la implementación, conéctese a la máquina virtual mediante RDP. Para ver la máquina virtual en
acción, se instala el servidor web IIS.
Para ver la dirección IP pública de la máquina virtual, use el cmdlet Get-AzPublicIpAddress:
Get-AzPublicIpAddress -ResourceGroupName "myResourceGroup" | Select "IpAddress"
Use el comando siguiente para crear una sesión de Escritorio remoto desde el equipo local. Reemplace la
dirección IP por la dirección IP pública de la máquina virtual.
mstsc /v:publicIpAddress
En la ventana Seguridad de Windows, seleccione Más opciones y, después, Usar otra cuenta. Escriba el
nombre de usuario como localhost\username, escriba la contraseña que creó para la máquina virtual y luego
haga clic en Aceptar.
Puede recibir una advertencia de certificado durante el proceso de inicio de sesión. Haga clic en Sí o en

Para ver la máquina virtual en acción, instale el servidor web IIS. Abra un símbolo del sistema de PowerShell en
la máquina virtual y ejecute el siguiente comando:
Visualización del servidor web en acción

Con IIS instalado y el puerto 80 abierto en la máquina virtual desde Internet, use el explorador web que prefiera
para ver la página principal predeterminada de IIS. Use la dirección IP pública de la máquina virtual que obtuvo
en el paso anterior. En el ejemplo siguiente se muestra el sitio web de IIS predeterminado:
Cuando ya no se necesiten, puede usar el cmdlet Remove-AzResourceGroup para quitar el grupo de recursos, la
VM y todos los recursos relacionados:
Remove-AzResourceGroup -Name myResourceGroup
Pasos siguientes
Inicio rápido: Creación de una máquina virtual
Windows con la CLI de Azure
La CLI de Azure se usa para crear y administrar recursos de Azure desde la línea de comandos o en scripts. En esta
guía de inicio rápido se muestra como usar la CLI de Azure para implementar una máquina virtual en Azure que
ejecute Windows Server 2016. Para ver la máquina virtual en acción, conéctese a la máquina virtual mediante RDP
e instale al servidor web IIS.

Azure Cloud Shell es un shell interactivo gratuito que puede usar para ejecutar los pasos de este artículo. Tiene las
herramientas comunes de Azure preinstaladas y configuradas para usarlas en la cuenta.
puede ir a https://shell.azure.com/bash para iniciar Cloud Shell en una pestaña independiente del explorador.
Seleccione Copiar para copiar los bloques de código, péguelos en Cloud Shell y, luego, presione Entrar para
ejecutarlos.
Crear un grupo de recursos

Cree un grupo de recursos con el comando az group create. Un grupo de recursos de Azure es un contenedor
lógico en el que se implementan y se administran los recursos de Azure. En el ejemplo siguiente, se crea un grupo
de recursos denominado myResourceGroup en la ubicación eastus:
az group create --name myResourceGroup --location eastus

Cree la máquina virtual con az vm create. En el ejemplo siguiente se crea una máquina virtual denominada myVM.
En este ejemplo se usa azureuser como nombre de un usuario administrativo.
Debe cambiar el valor de --admin-password o se producirá un error. Cámbielo por una contraseña que cumpla los
requisitos de contraseña de las máquinas virtuales de Azure. El nombre de usuario y la contraseña se usarán más
adelante cuando se conecte a la máquina virtual.
az vm create \
--resource-group myResourceGroup \
--name myVM \
--image win2016datacenter \
--admin-username azureuser \
--admin-password myPassword
La creación de la máquina virtual y los recursos auxiliares tarda unos minutos en realizarse. En la salida de ejemplo
siguiente se muestra que la operación de creación de la máquina virtual se realizó correctamente.
{
"fqdns": "",
"id":
"/subscriptions/<guid>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM",
"location": "eastus",
"macAddress": "00-0D-3A-23-9A-49",
"powerState": "VM running",
"privateIpAddress": "10.0.0.4",
"publicIpAddress": "52.174.34.95",
"resourceGroup": "myResourceGroup"
}
Tenga en cuenta sus propios valores de publicIpAddress en la salida de la máquina virtual. Esta dirección se usa
para acceder a la máquina virtual en los siguientes pasos.
Apertura del puerto 80 para el tráfico web

De forma predeterminada, solo las conexiones de RDP se abren al crease una máquina virtual Windows en Azure.
Use az vm open-port para abrir el puerto TCP 80 que se usará con el servidor web de IIS:
az vm open-port --port 80 --resource-group myResourceGroup --name myVM

Use el comando siguiente para crear una sesión de Escritorio remoto desde el equipo local. Reemplace la dirección
IP por la dirección IP pública de la máquina virtual. Cuando se le solicite, escriba las credenciales usadas al crear la
máquina virtual:
mstsc /v:publicIpAddress

Para ver la máquina virtual en acción, instale el servidor web IIS. Abra un símbolo del sistema de PowerShell en la
máquina virtual y ejecute el siguiente comando:
Visualización del servidor web en acción

Con IIS instalado y el puerto 80 abierto en la máquina virtual desde Internet, use el explorador web que prefiera
para ver la página principal predeterminada de IIS. Use la dirección IP pública de la máquina virtual que obtuvo en
el paso anterior. En el ejemplo siguiente se muestra el sitio web de IIS predeterminado:
Cuando ya no los necesite, puede usar el comando az group delete para eliminar el grupo de recursos, la máquina
virtual y todos los recursos relacionados:
az group delete --name myResourceGroup
Pasos siguientes
Tutorial: Creación y administración de máquinas
virtuales Windows con Azure PowerShell
Las máquinas virtuales de Azure proporcionan un entorno informático completamente configurable y flexible.
En este tutorial se tratan tareas básicas de la implementación de máquinas virtuales de Azure, como la selección
de su tamaño, la selección de una imagen de máquina virtual y la implementación de una máquina virtual.
Aprenderá a:
Crear y conectar elementos a una máquina virtual
Seleccionar y usar imágenes de máquinas virtuales
Ver y usar tamaños de una máquina virtual específicos
Cambiar el tamaño de una máquina virtual
Ver y entender el estado de las máquinas virtuales.


Cree un grupo de recursos con el comando New -AzResourceGroup.
Un grupo de recursos de Azure es un contenedor lógico en el que se implementan y se administran los recursos
de Azure. Se debe crear un grupo de recursos antes de una máquina virtual. En el siguiente ejemplo, se crea un
grupo de recursos denominado myResourceGroupVM en la región EastUS:
New-AzResourceGroup `
-ResourceGroupName "myResourceGroupVM" `
-Location "EastUS"
Se especifica el grupo de recursos al crear o modificar una máquina virtual, como se ve a lo largo de este
tutorial.
Crear una VM
Al crear una máquina virtual, hay varias opciones disponibles, como la imagen del sistema operativo, la
configuración de red y las credenciales administrativas. En este ejemplo se crea una máquina virtual
denominada myVM que ejecuta la versión predeterminada de Windows Server 2016 Datacenter.
Establezca el nombre de usuario y la contraseña que se necesitan para la cuenta de administrador en la máquina
virtual con Get-Credential:
$cred = Get-Credential
Cree la máquina virtual con New -AzVM.
New-AzVm `
-Name "myVM" `
-Location "EastUS" `
-Credential $cred
Conexión con una máquina virtual

Una vez finalizada la implementación, cree una conexión del escritorio remoto con la máquina virtual.
Ejecute los siguientes comandos para devolver la dirección IP pública de la máquina virtual. Tome nota de esta
dirección IP para poder conectarse a ella con un explorador para probar la conectividad web en un paso
posterior.
Get-AzPublicIpAddress `
-ResourceGroupName "myResourceGroupVM" | Select IpAddress
Ejecute el siguiente comando en la máquina local para crear una sesión de escritorio remoto con la máquina
virtual. Reemplace la dirección IP por el valor de publicIPAddress de la máquina virtual. Cuando se le solicite,
escriba las credenciales usadas al crear la máquina virtual.
mstsc /v:<publicIpAddress>
En la ventana Seguridad de Windows, seleccione Más opciones y, después, Usar otra cuenta. Escriba el
nombre de usuario y la contraseña que creó para la máquina virtual y haga clic en Aceptar.
Descripción de las imágenes de Marketplace

Azure Marketplace incluye muchas imágenes que pueden usarse para crear una máquina virtual. En los pasos
anteriores se creó una máquina virtual mediante la imagen de Windows Server 2016 Datacenter. En este paso,
el módulo de PowerShell se usa para buscar en Marketplace otras imágenes de Windows, que también se
pueden usar como base para nuevas máquinas virtuales. Este proceso consiste en buscar el publicador, la oferta,
la SKU y, opcionalmente, un número de versión para identificar la imagen.
Use el comando Get-AzVMImagePublisher para devolver una lista de publicadores de imágenes:
Get-AzVMImagePublisher -Location "EastUS"
Use el comando Get-AzVMImageOffer para devolver una lista de ofertas de imágenes. Con este comando, la
lista devuelta se filtra por el publicador especificado denominado MicrosoftWindowsServer :
Get-AzVMImageOffer `
-PublisherName "MicrosoftWindowsServer"
Los resultados deberán tener un aspecto similar a este ejemplo:
Offer PublisherName Location

----- ------------- --------
Windows-HUB MicrosoftWindowsServer EastUS
WindowsServer MicrosoftWindowsServer EastUS
WindowsServer-HUB MicrosoftWindowsServer EastUS
El comando Get-AzVMImageSku filtrará entonces por el publicador y el nombre de la oferta para devolver una
lista de nombres de imágenes.
Get-AzVMImageSku `
-PublisherName "MicrosoftWindowsServer" `
-Offer "WindowsServer"
Los resultados deberán tener un aspecto similar a este ejemplo:
Skus Offer PublisherName Location

---- ----- ------------- --------
2008-R2-SP1 WindowsServer MicrosoftWindowsServer EastUS
2008-R2-SP1-smalldisk WindowsServer MicrosoftWindowsServer EastUS
2012-Datacenter WindowsServer MicrosoftWindowsServer EastUS
2012-Datacenter-smalldisk WindowsServer MicrosoftWindowsServer EastUS
2012-R2-Datacenter WindowsServer MicrosoftWindowsServer EastUS
2012-R2-Datacenter-smalldisk WindowsServer MicrosoftWindowsServer EastUS
2016-Datacenter WindowsServer MicrosoftWindowsServer EastUS
2016-Datacenter-Server-Core WindowsServer MicrosoftWindowsServer EastUS
2016-Datacenter-Server-Core-smalldisk WindowsServer MicrosoftWindowsServer EastUS
2016-Datacenter-smalldisk WindowsServer MicrosoftWindowsServer EastUS
2016-Datacenter-with-Containers WindowsServer MicrosoftWindowsServer EastUS
2016-Datacenter-with-Containers-smalldisk WindowsServer MicrosoftWindowsServer EastUS
2016-Datacenter-with-RDSH WindowsServer MicrosoftWindowsServer EastUS
2016-Nano-Server WindowsServer MicrosoftWindowsServer EastUS
Esta información puede usarse para implementar una máquina virtual con una imagen específica. En este
ejemplo se implementa una máquina virtual mediante la versión más reciente de Windows Server 2016 con una
imagen de Containers.
New-AzVm `
-Name "myVM2" `
-PublicIpAddressName "myPublicIpAddress2" `
-ImageName "MicrosoftWindowsServer:WindowsServer:2016-Datacenter-with-Containers:latest" `
-Credential $cred `
-AsJob
El parámetro -AsJob crea la máquina virtual como tarea en segundo plano, por lo que PowerShell solicita la
vuelta. Puede ver detalles de trabajos en segundo plano con el cmdlet Get-Job .
Comprensión de los tamaños de máquina virtual

El tamaño de la máquina virtual determina la cantidad de recursos de proceso, como memoria, CPU y GPU, que
están disponibles para la máquina virtual. Las máquinas virtuales deben crearse con un tamaño de máquina
virtual adecuado para la carga de trabajo. Si esta aumenta, también se puede cambiar el tamaño de las máquinas
virtuales existentes.
Tamaños de máquina virtual
En la tabla siguiente se clasifican los tamaños en casos de uso.
TYPE TAMAÑOS COMUNES DESCRIPCIÓN
Uso general B, Dsv3, Dv3, DSv2, Dv2, Av2, DC Uso equilibrado de CPU y memoria.
Ideal para desarrollo/pruebas, así como
soluciones de datos y aplicaciones de
tamaño pequeño a mediano.
Proceso optimizado Fsv2 Uso elevado de la CPU respecto a la

memoria. Adecuado para aplicaciones,
dispositivos de red y procesos por lotes
con tráfico mediano.
Memoria optimizada Esv3, Ev3, M, DSv2, Dv2 Uso elevado de memoria respecto al
núcleo. Excelente para bases de datos
relacionales, memorias caché de
capacidad de mediana a grande y
análisis en memoria.
Almacenamiento optimizado Lsv2, Ls Alto rendimiento de disco y E/S.

Perfecto para bases de datos SQL y
NoSQL y macrodatos.
GPU NV, NVv2, NC, NCv2, NCv3, ND Máquinas virtuales especializadas para
actividades intensas de representación
de gráficos y edición de vídeo.
Alto rendimiento H Nuestras máquinas virtuales con CPU

más eficaces e interfaces de red de alto
rendimiento (RDMA) opcionales.
Búsqueda de los tamaños de máquina virtual disponibles

Para ver una lista de tamaños de máquina virtual disponibles en una región determinada, use el comando Get-
AzVMSize.
Get-AzVMSize -Location "EastUS"

Una vez implementada una máquina virtual, se puede cambiar su tamaño para aumentar o disminuir la
asignación de recursos.
Antes de cambiar el tamaño de una máquina virtual, compruebe si el tamaño deseado está disponible en el
clúster actual de máquinas virtuales. El comando Get-AzVMSize devuelve una lista de tamaños.
Get-AzVMSize -ResourceGroupName "myResourceGroupVM" -VMName "myVM"
Si el tamaño está disponible, puede cambiarlo con la máquina virtual encendida, aunque se reiniciará durante la
operación.
$vm = Get-AzVM `
-VMName "myVM"
$vm.HardwareProfile.VmSize = "Standard_DS3_v2"
Update-AzVM `
-VM $vm `
-ResourceGroupName "myResourceGroupVM"
Si el tamaño que desea no está disponible en el clúster actual, se debe desasignar la máquina virtual para que se
pueda llevar a cabo la operación de cambio de tamaño. La desasignación de una máquina virtual se traduce en la
eliminación de los datos del disco temporal y la dirección IP pública cambiará, a menos que se use una dirección
IP estática.
Stop-AzVM `
-Name "myVM" -Force
$vm = Get-AzVM `
-VMName "myVM"
$vm.HardwareProfile.VmSize = "Standard_E2s_v3"
Update-AzVM -VM $vm `
-ResourceGroupName "myResourceGroupVM"
Start-AzVM `
-Name $vm.name
Estados de energía de una máquina virtual

Una máquina virtual de Azure puede tener uno de muchos estados de energía.
ESTADO DE ENERGÍA DESCRIPCIÓN
Iniciando La máquina virtual se está iniciando.
En ejecución La máquina virtual se está ejecutando.
Deteniéndose La máquina virtual se está deteniendo.
Detenido La máquina virtual está detenida. Las máquinas virtuales en

el estado detenido siguen acumulando cargos por procesos.
Desasignando La máquina virtual se está desasignando.
Desasignado Indica que la máquina virtual se quitó del hipervisor, pero

sigue estando disponible en el plano de control. Las
máquinas virtuales en el estado Deallocated no incurren
en cargos por los procesos.
- Se desconoce el estado de la máquina virtual.
Para recuperar el estado de una máquina virtual concreta, use el comando Get-AzVM. Asegúrese de especificar
un nombre válido para la máquina virtual y el grupo de recursos.
Get-AzVM `
-Name "myVM" `
-Status | Select @{n="Status"; e={$_.Statuses[1].Code}}
El resultado tendrá un aspecto similar al siguiente ejemplo:
Status
------
PowerState/running
Tareas de administración
Durante el ciclo de vida de una máquina virtual, puede que desee ejecutar tareas de administración como
iniciarla, detenerla o eliminarla. Además, puede crear scripts para automatizar tareas repetitivas o complejas.
Con Azure PowerShell, se pueden ejecutar muchas tareas comunes de administración desde la línea de
comandos o en scripts.
Detención de una máquina virtual
Detenga y desasigne una máquina virtual con Stop-AzVM:
Stop-AzVM `
-Name "myVM" -Force
Si desea mantener la máquina virtual en un estado aprovisionado, use el parámetro -StayProvisioned.

Inicio de una máquina virtual
Start-AzVM `
-Name "myVM"
Eliminación de un grupo de recursos

Todo el contenido dentro de un grupo de recursos se elimina al eliminar el grupo de recursos.
Remove-AzResourceGroup `
-Name "myResourceGroupVM" `
-Force
Pasos siguientes
En este tutorial, ha aprendido conceptos básicos sobre la creación y administración de máquinas virtuales. Por
ejemplo:
Crear y conectar elementos a una máquina virtual.
Seleccionar y usar imágenes de máquinas virtuales
Ver y usar tamaños de una máquina virtual específicos
Ver y entender el estado de las máquinas virtuales.
Prosiga con el siguiente tutorial para aprender sobre los discos en máquinas virtuales.
Creación y administración de discos de máquinas virtuales
Tutorial: Administración de discos de Azure con
Azure PowerShell
Las máquinas virtuales de Azure usan discos para almacenar el sistema operativo, las aplicaciones y los datos de
máquinas virtuales. Al crear una máquina virtual es importante elegir un tamaño de disco y la configuración
adecuada para la carga de trabajo esperada. Este tutorial trata la implementación y administración de discos de
máquina virtual. Aprenderá sobre los siguientes temas:
Discos del SO y temporales.
Discos de datos.
Discos Estándar y Premium.
Rendimiento de disco.
Conectar y preparar los discos de datos

puede ir a https://shell.azure.com/powershell para iniciar Cloud Shell en una pestaña independiente del explorador.
ejecutarlos.
Discos de Azure predeterminados

Cuando se crea una máquina virtual de Azure, se conectan dos discos automáticamente a la máquina virtual.
Disco del sistema operativo: hospeda el sistema operativo de las máquinas virtuales. Se puede cambiar su
tamaño hasta 4 terabyte. Al disco del sistema operativo se le asigna la letra de unidad C: de forma predeterminada.
La configuración de almacenamiento en caché del disco del sistema operativo está optimizada para el rendimiento
del sistema operativo. El disco del sistema operativo no debería hospedar aplicaciones o datos. Para aplicaciones
y datos, use un disco de datos. Explicamos esto más adelante en este artículo.
Disco temporal: los discos temporales utilizan una unidad de estado sólida que se encuentra en el mismo host de
Azure que la máquina virtual. Los discos temporales son muy eficiente y se pueden usar para operaciones tales
como el procesamiento temporal de los datos. Sin embargo, si la máquina virtual se mueve a un nuevo host, los
datos almacenados en un disco temporal se eliminarán. El tamaño del disco temporal lo determina el tamaño de la
máquina virtual. A los discos temporales se les asigna la letra de unidad D: de forma predeterminada.
Discos de datos de Azure

Se pueden agregar discos de datos adicionales para instalar aplicaciones y almacenar datos. Los discos de datos
deben usarse en cualquier situación donde se necesite un almacenamiento de datos duradero y con capacidad de
respuesta. El tamaño de la máquina virtual determina cuántos discos de datos se pueden conectar a una máquina
virtual. Para cada CPU virtual de la máquina virtual, se pueden asociar cuatro discos de datos.
Tipos de disco de máquina virtual

Azure proporciona dos tipos de discos.
Discos estándar: respaldados por unidades de disco duro, ofrecen un almacenamiento rentable y buen
rendimiento. Los discos estándar son ideales para cargas de trabajo de desarrollo y prueba rentables.
Discos Premium: respaldados por un disco de latencia reducida y alto rendimiento basado en SSD. Es perfecto
para máquinas virtuales que ejecutan cargas de trabajo de producción. Premium Storage es compatible con las
máquinas virtuales de las series DS, DSv2, GS y FS. Los discos Premium incluyen cinco tipos (P10, P20, P30, P40
y P50); el tamaño del disco determina el tipo de disco. Al seleccionar el tamaño de un disco, el valor se redondea al
siguiente tipo. Por ejemplo, si el tamaño es inferior a 128 GB, el tipo de disco es P10; si es de 129 a 512 GB, el
disco es P20.
Rendimiento del disco Premium
TAM
AÑO
S DE
SSD
PRE
MIU
M P1* P2* P3* P4 P6 P10 P15 P20 P30 P40 P50 P60 P70 P80
Tam 4 8 16 32 64 128 256 512 102 2 4 819 16 32

año 4 048 096 2 384 767
de
disc
o
en
GiB
IOP 120 120 120 120 240 500 110 2,30 5.00 750 750 16 18 20.0
S 0 0 0 0 0 000 000 00
por
disc
o
Ren 25 25 25 25 50 100 125 150 200 250 250 500 750 900
dimi MiB MiB MiB MiB MiB Mi Mi MiB Mi Mi Mi Mi Mi Mi
ent /s /s /s /s /s B/s B/s /s B/s B/s B/s B/s B/s B/s
o
de
disc
o.
Máx 350 350 350 350 350 350 350 350

imo 0 0 0 0 0 0 0 0
de
IOP
S de
ráfa
ga
por
disc
o**
TAM
AÑO
S DE
SSD
PRE
MIU
Ren 170 170 170 170 170 170 170 170

dimi Mi Mi Mi Mi Mi Mi Mi Mi
ent B/s B/s B/s B/s B/s B/s B/s B/s
o
máx
imo
de
ráfa
ga
por
disc
o**
Dur 30 30 30 30 30 30 30 30
ació min min min min min min min min
n
máx
ima
de
ráfa
ga*
*
*Indica un tamaño de disco que se encuentra actualmente en versión preliminar; para información sobre la
disponibilidad regional, consulte Nuevos tamaños de disco: Administrados y no administrados.
**Indica una característica que se encuentra actualmente en versión preliminar; consulte Envío de ráfagas en disco
para más información.
Aunque la tabla anterior identifica las IOPS máximas por disco, se puede obtener un mayor nivel de rendimiento
dividiendo varios discos de datos. Por ejemplo, 64 discos de datos pueden conectarse a la máquina virtual
Standard_GS5. Si cada uno de estos discos tiene un tamaño P30, se puede lograr un máximo de 80 000 IOPS.
Para más información sobre el número máximo de IOPS por máquina virtual, vea los tamaños y topos de
máquinas virtuales.
Creación y conexión de discos

Para completar el ejemplo de este tutorial, debe tener una máquina virtual. Si es necesario, cree una máquina
virtual con los siguientes comandos.
Cree la máquina virtual con New -AzVM. Se le pedirá que escriba un nombre de usuario y una contraseña para la
cuenta de administrador de la máquina virtual.
New-AzVm `
-ResourceGroupName "myResourceGroupDisk" `
-Name "myVM" `
-PublicIpAddressName "myPublicIpAddress"
Cree la configuración inicial con New -AzDiskConfig. En el ejemplo siguiente se crea un disco denominado con un
tamaño de 128 gigabytes.
$diskConfig = New-AzDiskConfig `
-CreateOption Empty `
-DiskSizeGB 128
Cree el disco de datos con el comando New -AzDisk.
$dataDisk = New-AzDisk `
-ResourceGroupName "myResourceGroupDisk" `
-DiskName "myDataDisk" `
-Disk $diskConfig
Obtenga la máquina virtual que desea agregar al disco de datos con el comando Get-AzVM.
$vm = Get-AzVM -ResourceGroupName "myResourceGroupDisk" -Name "myVM"
Agregue el disco de datos a la configuración de máquina virtual con el comando Add-AzVMDataDisk.
$vm = Add-AzVMDataDisk `
-VM $vm `
-Name "myDataDisk" `
-CreateOption Attach `
-ManagedDiskId $dataDisk.Id `
-Lun 1
Actualice la máquina virtual con el comando Update-AzVM.
Update-AzVM -ResourceGroupName "myResourceGroupDisk" -VM $vm
Preparación de los discos de datos

Cuando se haya conectado un disco a la máquina virtual, el sistema operativo debe configurarse para utilizar el
disco. En el ejemplo siguiente se muestra cómo configurar manualmente el primer disco que se agrega a la
máquina virtual. Este proceso también se puede automatizar utilizando la extensión de script personalizado.
Configuración manual
Crear una conexión RDP con la máquina virtual. Abra PowerShell y ejecute este script.
Get-Disk | Where partitionstyle -eq 'raw' |
Initialize-Disk -PartitionStyle MBR -PassThru |
New-Partition -AssignDriveLetter -UseMaximumSize |
Format-Volume -FileSystem NTFS -NewFileSystemLabel "myDataDisk" -Confirm:$false
Comprobación de los datos

Para comprobar que el disco de datos está conectado, consulte StorageProfile de los discos DataDisks
conectados.
$vm.StorageProfile.DataDisks
El resultado debe parecerse a este ejemplo:
Name : myDataDisk
DiskSizeGB : 128
Lun : 1
Caching : None
CreateOption : Attach
SourceImage :
VirtualHardDisk :
Pasos siguientes
En este tutorial, ha aprendido sobre temas relacionados con los discos de máquina virtual; por ejemplo:
Discos del SO y temporales.
Discos de datos.
Discos Estándar y Premium.
Rendimiento de disco.
Conectar y preparar los discos de datos
Siga con el siguiente tutorial para aprender sobre la automatización de la configuración de la máquina virtual.
Automatización de la configuración de máquinas virtuales
Tutorial: Implementación de aplicaciones en una
máquina virtual Windows en Azure con la extensión
de script personalizado
Para configurar las máquinas virtuales (VM ) de una manera rápida y coherente, puede usar la extensión de script
personalizado para Windows. En este tutorial, aprenderá a:
Usar la extensión de script personalizada para instalar IIS
Crear una máquina virtual que use la extensión de script personalizada
Ver un sitio IIS en funcionamiento después de aplicar la extensión

Información general de la extensión de script personalizado

La extensión de script personalizado descarga y ejecuta scripts en máquinas virtuales de Azure. Esta extensión es
útil para la configuración posterior a la implementación, la instalación de software o cualquier otra tarea de
configuración o administración. Los scripts se pueden descargar desde Azure Storage o GitHub, o se pueden
proporcionar a Azure Portal en el tiempo de ejecución de la extensión.
La extensión de script personalizado se integra con las plantillas de Azure Resource Manager y también se puede
ejecutar mediante la CLI de Azure, PowerShell, Azure Portal o la API de REST de máquina virtual de Azure.
Se puede usar la extensión de script personalizado con máquinas virtuales de Linux y Windows.

Establezca un nombre de usuario de administrador y una contraseña para la máquina virtual con Get-Credential:
Ahora puede crear la máquina virtual con New -AzVM. En el ejemplo siguiente se crea una máquina virtual
denominada myVM en la ubicación EastUS. Si aún no existen, se crean el grupo de recursos
myResourceGroupAutomate y los recursos de red de soporte. Para permitir el tráfico de web, el cmdlet también
abre el puerto 80.
New-AzVm `
-ResourceGroupName "myResourceGroupAutomate" `
-Name "myVM" `
-OpenPorts 80 `
-Credential $cred
Los recursos y la máquina virtual tardan unos minutos en crearse.
Automatizar la instalación de IIS

Use Set-AzVMExtension para instalar la extensión de script personalizado. La extensión ejecuta
powershell Add-WindowsFeature Web-Server para instalar el servidor web de IIS y después actualiza la página
Default.htm para mostrar el nombre de host de la máquina virtual:
Set-AzVMExtension -ResourceGroupName "myResourceGroupAutomate" `

-ExtensionName "IIS" `
-VMName "myVM" `
-Publisher Microsoft.Compute `
-ExtensionType CustomScriptExtension `
-TypeHandlerVersion 1.8 `
-SettingString '{"commandToExecute":"powershell Add-WindowsFeature Web-Server; powershell Add-Content -
Path \"C:\\inetpub\\wwwroot\\Default.htm\" -Value $($env:computername)"}'
Sitio web de prueba

Obtenga la dirección IP pública del equilibrador de carga con Get-AzPublicIPAddress. En el ejemplo siguiente se
obtiene la dirección IP de myPublicIPAddress que se ha creado anteriormente:
Get-AzPublicIPAddress `
-ResourceGroupName "myResourceGroupAutomate" `
-Name "myPublicIPAddress" | select IpAddress
A continuación, puede escribir la dirección IP pública en un explorador web. Se muestra el sitio web, incluido el
nombre de host de la máquina virtual a la que el equilibrador de carga distribuye el tráfico como en el ejemplo
siguiente:
Pasos siguientes
En este tutorial, automatizó la instalación IIS en una máquina virtual. Ha aprendido a:
Usar la extensión de script personalizada para instalar IIS
Crear una máquina virtual que use la extensión de script personalizada
Ver un sitio IIS en funcionamiento después de aplicar la extensión
Avanzar al siguiente tutorial para aprender a crear imágenes de máquina virtual personalizadas.
Creación de imágenes personalizadas de máquinas virtuales
Tutorial: Creación de una imagen personalizada de
una máquina virtual de Azure con Azure PowerShell
Las imágenes personalizadas son como las imágenes de Marketplace, pero las puede crear usted mismo. Las
imágenes personalizadas pueden usarse en el arranque de las implementaciones y para garantizar la coherencia
entre varias máquinas virtuales. En este tutorial, creará su propia imagen personalizada de una máquina virtual
de Azure con PowerShell. Aprenderá a:
Ejecutar Sysprep y generalizar máquinas virtuales
Crear una imagen personalizada
Crear una imagen personalizada a partir de una máquina virtual
Enumerar todas las imágenes en su suscripción
Eliminar una imagen
En la versión preliminar pública, tenemos el servicio Image Builder de Azure para máquinas virtuales. Solo tiene
que describir sus personalizaciones en una plantilla y esta servirá para llevar a cabo los pasos de creación de
imágenes de este artículo. Pruebe Azure Image Builder (versión preliminar).
Antes de empezar
Los siguientes pasos explican cómo tomar una máquina virtual existente y convertirla en una imagen
personalizada reutilizable que puede usar para crear nuevas instancias de máquinas virtuales.
Para completar el ejemplo de este tutorial, debe tener una máquina virtual. Si es necesario, este script de ejemplo
puede crear una. Al trabajar en el tutorial, reemplace los nombres de grupo de recursos y máquina virtual cuando
proceda.

Preparación de la VM
Para crear una imagen de una máquina virtual, debe preparar la máquina virtual de origen; para ello, debe
generalizarla, desasignarla y después marcarla como generalizada con Azure.
Generalización de VM con Windows mediante Sysprep
Entre otras características, Sysprep elimina toda la información personal de la cuenta y prepara, entre otras cosas,
la máquina para usarse como imagen. Para más información acerca de Sysprep, consulte Uso de Sysprep:
Introducción.
1. Conexión a una máquina virtual.
2. Abra una ventana del símbolo del sistema como administrador. Cambie el directorio a
%windir%\system32\sysprep y, después, ejecute sysprep.exe .
3. En Herramienta de preparación del sistema, seleccione Iniciar la Configuración rápida (OOBE ) y
asegúrese de que la casilla Generalizar está activada.
4. En Opciones de apagado, seleccione Apagar y, a continuación, haga clic en Aceptar.
5. Cuando Sysprep finaliza, apaga la máquina virtual. No reinicie la VM.
Desasignación y marcado de la VM como generalizada
Para crear una imagen, la VM debe desasignarse y estar marcada como generalizada en Azure.
Desasigne la máquina virtual mediante Stop-AzVM.
Stop-AzVM `
-ResourceGroupName myResourceGroup `
-Name myVM -Force
Establezca el estado de la máquina virtual en -Generalized mediante Set-AzVm.
Set-AzVM `
-Name myVM -Generalized
Crear la imagen
Ahora puede crear una imagen de la máquina virtual mediante New -AzImageConfig y New -AzImage. En el
ejemplo siguiente se crea una imagen denominada myImage a partir de la máquina virtual llamada myVM.
Obtenga la máquina virtual.
$vm = Get-AzVM `
-Name myVM `
-ResourceGroupName myResourceGroup
Cree la configuración de la imagen.
$image = New-AzImageConfig `
-Location EastUS `
-SourceVirtualMachineId $vm.ID
Cree la imagen.
New-AzImage `
-Image $image `
-ImageName myImage `
Creación de VM a partir de la imagen

Ahora que tiene una imagen, puede crear una o varias VM desde la imagen. Crear una máquina virtual a partir
de una imagen personalizada es muy similar a crear una máquina virtual mediante una imagen de Marketplace.
Cuando use una imagen de Marketplace, tendrá que proporcionar información sobre la imagen, el proveedor de
esa imagen, la oferta, la SKU y la versión. Mediante el parámetro simplificado establecido para el cmdlet New -
AzVM, basta con que proporcione el nombre de la imagen personalizada, siempre que se encuentre en el mismo
grupo de recursos.
En este ejemplo se crea una máquina virtual denominada myVMfromImage a partir de la imagen myImage, en
myResourceGroup.
New-AzVm `
-Name "myVMfromImage" `
-ImageName "myImage" `
-VirtualNetworkName "myImageVnet" `
-SubnetName "myImageSubnet" `
-SecurityGroupName "myImageNSG" `
-PublicIpAddressName "myImagePIP" `
-OpenPorts 3389
Se recomienda limitar el número de implementaciones simultáneas a 20 máquinas virtuales desde una sola
imagen. Si planea realizar implementaciones simultáneas a gran escala de más de 20 máquinas virtuales a partir
de la misma imagen personalizada, debe usar Shared Image Gallery con varias réplicas de imágenes.
Administración de imágenes
Estos son algunos ejemplos de tareas de imágenes administradas comunes y cómo completarlas con PowerShell.
Enumere todas las imágenes por nombre.
$images = Get-AzResource -ResourceType Microsoft.Compute/images

$images.name
Elimine una imagen. Este ejemplo elimina la imagen myImage de myResourceGroup.
Remove-AzImage `
Pasos siguientes
En este tutorial, ha creado una imagen de máquina virtual personalizada. Ha aprendido a:
Ejecutar Sysprep y generalizar máquinas virtuales
Crear una imagen personalizada
Crear una imagen personalizada a partir de una máquina virtual
Enumerar todas las imágenes en su suscripción
Eliminar una imagen
En al siguiente tutorial aprenderá a crear máquinas virtuales de alta disponibilidad.
Creación de máquinas virtuales de alta disponibilidad
Tutorial: Creación e implementación de máquinas
virtuales de alta disponibilidad con Azure
PowerShell
En este tutorial, obtendrá información sobre cómo aumentar la disponibilidad y confiabilidad de Virtual
Machines mediante conjuntos de disponibilidad. Los conjuntos de disponibilidad garantizan que las máquinas
virtuales implementadas en Azure se distribuyan entre varios nodos de hardware aislados en un clúster.
En este tutorial, aprenderá a:
Crear un conjunto de disponibilidad
Crear una máquina virtual en un conjunto de disponibilidad
Comprobar los tamaños de máquina virtual disponibles
Comprobar Azure Advisor
Información general sobre conjuntos de disponibilidad

Un conjunto de disponibilidad es una funcionalidad de agrupación lógica para aislar los recursos de máquina
virtual entre sí cuando se implementan. Azure garantiza que las máquinas virtuales colocadas en un conjunto de
disponibilidad se ejecuten en varios servidores físicos, grupos de proceso, unidades de almacenamiento y
conmutadores de red. Si se produce un error de hardware o software, solo un subconjunto de las máquinas
virtuales se ve afectado y la solución general permanece operativa. Los conjuntos de disponibilidad son
esenciales para la creación de soluciones en la nube confiables.
Veamos una solución basada en máquina virtual típica en la podría haber cuatro servidores web front-end y dos
máquinas virtuales de back-end. Con Azure, desea definir dos conjuntos de disponibilidad antes de implementar
las máquinas virtuales: uno para el nivel de web y otro para el nivel de back-end. Al crear una nueva máquina
virtual, especifique el conjunto de disponibilidad como un parámetro. Azure garantiza que las máquinas virtuales
están aisladas en varios recursos de hardware físico. Si el hardware físico que uno de los servidores ejecuta tiene
un problema, sabe que las restantes instancias de los servidores siguen ejecutándose correctamente porque
están en otro hardware.
Use los conjuntos de disponibilidad cuando quiera implementar soluciones basadas en máquinas virtuales
confiables en Azure.


El hardware de una ubicación está dividido en varios dominios de actualización y de error. Un dominio de
actualización es un grupo de máquinas virtuales y hardware físico subyacente que se pueden reiniciar al
mismo tiempo. Las máquinas virtuales en el mismo dominio de error comparten un almacenamiento común,
así como una fuente de alimentación y un conmutador de red comunes.
Puede crear un conjunto de disponibilidad con New -AzAvailabilitySet. En este ejemplo, el número de dominios
de error y de actualización es 2, y el conjunto de disponibilidad se denomina myAvailabilitySet.
Cree un grupo de recursos.
-Name myResourceGroupAvailability `
-Location EastUS
Cree un conjunto de disponibilidad administrado mediante New -AzAvailabilitySet con el parámetro

-sku aligned .
New-AzAvailabilitySet `
-Name "myAvailabilitySet" `
-ResourceGroupName "myResourceGroupAvailability" `
-Sku aligned `
-PlatformFaultDomainCount 2 `
-PlatformUpdateDomainCount 2
Creación de VM dentro de un conjunto de disponibilidad

Las máquinas virtuales deben crearse en el conjunto de disponibilidad para asegurarse de que se distribuyan
correctamente en el hardware. No se puede agregar una máquina virtual existente a un conjunto de
disponibilidad después de crearla.
Al crear una máquina virtual mediante New -AzVM, con el parámetro -AvailabilitySetName se especifica el
nombre del conjunto de disponibilidad.
En primer lugar, establezca un nombre de usuario de administrador y una contraseña para la máquina virtual con
Get-Credential:
Ahora, cree dos máquinas virtuales con New -AzVM en el conjunto de disponibilidad.
for ($i=1; $i -le 2; $i++)

{
New-AzVm `
-Name "myVM$i" `
-PublicIpAddressName "myPublicIpAddress$i" `
-AvailabilitySetName "myAvailabilitySet" `
-Credential $cred
}
Se tarda unos minutos en crear y configurar ambas VM. Al terminar, tendrá dos máquinas virtuales distribuidas
en el hardware subyacente.
Si observa el conjunto de disponibilidad en el portal en Grupos de recursos > myResourceGroupAvailability
> myAvailabilitySet, debería ver cómo se distribuyen las máquinas virtuales en ambos dominios, el de error y
el de actualización.
Comprobación de los tamaños de VM disponibles

Se pueden agregar más máquinas virtuales al conjunto de disponibilidad posteriormente, pero debe saber qué
tamaños de máquina virtual están disponibles en el hardware. Use Get-AzVMSize para enumerar todos los
tamaños disponibles en el clúster de hardware para el conjunto de disponibilidad.
Get-AzVMSize `
-AvailabilitySetName "myAvailabilitySet"

También puede usar Azure Advisor para más información acerca de las distintas maneras de mejorar la
disponibilidad de las máquinas virtuales. Azure Advisor analiza la configuración de los recursos y la telemetría de
uso, y recomienda soluciones que pueden ayudar a mejorar la rentabilidad, el rendimiento, la alta disponibilidad
y la seguridad de los recursos de Azure.
Inicie sesión en Azure Portal, seleccione Todos los servicios y escriba Advisor. El panel de Advisor muestra
recomendaciones personalizadas de la suscripción seleccionada. Para más información, consulte Introducción
con Azure Advisor.
Pasos siguientes
En este tutorial aprendió lo siguiente:
Crear una máquina virtual en un conjunto de disponibilidad
Comprobar los tamaños de máquina virtual disponibles
Avance al siguiente tutorial para informarse sobre los conjuntos de escalado de máquinas virtuales.
Creación de un conjunto de escalado de máquinas virtuales
Tutorial: Creación de un conjunto de escalado de
máquinas virtuales e implementación de una
aplicación de alta disponibilidad en Windows con
Azure PowerShell
Un conjunto de escalado de máquinas virtuales le permite implementar y administrar un conjunto de máquinas

virtuales de escalado automático idénticas. Puede escalar el número de máquinas virtuales del conjunto de
escalado de forma manual. También puede definir reglas de escalado automático en función del uso de recursos
tales como la CPU, la demanda de memoria o el tráfico de red. En este tutorial, implementará un conjunto de
escalado de máquinas virtuales en Azure y aprenderá cómo:
Usar la extensión de script personalizada para definir un sitio IIS para escalar
Crear un equilibrador de carga para el conjunto de escalado
Crear un conjunto de escalado de máquinas virtuales
Aumentar o disminuir el número de instancias en un conjunto de escalado
Crear reglas de escalado automático

ejecutarlos.
Introducción al conjunto de escalado

Un conjunto de escalado de máquinas virtuales le permite implementar y administrar un conjunto de máquinas
virtuales de escalado automático idénticas. Las máquinas virtuales de un conjunto de escalado se distribuyen en
dominios lógicos de error y de actualización en uno o más grupos de selección de ubicación. Los grupos de
selección de ubicación son grupos de máquinas virtuales configuradas de manera similar, al igual que los
conjuntos de disponibilidad.
Las máquinas virtuales se crean según sea necesario en un conjunto de escalado. Defina reglas de escalado
automático para controlar cómo y cuándo se agregan o se quitan las máquinas virtuales del conjunto de escalado.
Estas reglas se pueden desencadenar en función de métricas como la carga de la CPU, el uso de la memoria o el
tráfico de red.
Los conjuntos de escalado admiten hasta 1000 máquinas virtuales cuando se usa una imagen de la plataforma de
Azure. Para las cargas de trabajo con requisitos de personalización de VM o instalación significativos, puede que
desee crear una imagen de VM personalizada. Puede crear hasta 300 máquinas virtuales en un conjunto de
escalado al usar una imagen personalizada.
Creación de un conjunto de escalado

Cree un conjunto de escalado de máquinas virtuales con New -AzVmss. En el ejemplo siguiente, se crea un
conjunto de escalado denominado myScaleSet que usa la imagen de plataforma Windows Server 2016
Datacenter. Los recursos de red de Azure para una red virtual, una dirección IP pública y un equilibrador de carga
se crean automáticamente. Cuando se le solicite, puede establecer sus propias credenciales administrativas para las
instancias de máquina virtual del conjunto de escalado:
New-AzVmss `
-ResourceGroupName "myResourceGroupScaleSet" `
-VMScaleSetName "myScaleSet" `
-PublicIpAddressName "myPublicIPAddress" `
-LoadBalancerName "myLoadBalancer" `
-UpgradePolicyMode "Automatic"
Se tardan unos minutos en crear y configurar todos los recursos de conjunto de escalado y máquinas virtuales.
Implementación de una aplicación de ejemplo

Para probar el conjunto de escalado, instale una aplicación web básica. La extensión de script personalizado de
Azure se usa para descargar y ejecutar un script que instala IIS en las instancias de máquina virtual. Esta extensión
es útil para la configuración posterior a la implementación, la instalación de software o cualquier otra tarea de
configuración o administración. Para obtener más información, consulte Información general de la extensión de
script personalizado.
Use la extensión de script personalizado para instalar un servidor web de IIS básico. Aplique la extensión de script
personalizada que instala IIS según se indica a continuación:
# Define the script for your Custom Script Extension to run

$publicSettings = @{
"fileUris" = (,"https://raw.githubusercontent.com/Azure-Samples/compute-automation-
configurations/master/automate-iis.ps1");
"commandToExecute" = "powershell -ExecutionPolicy Unrestricted -File automate-iis.ps1"
}
# Get information about the scale set

$vmss = Get-AzVmss `
-VMScaleSetName "myScaleSet"
# Use Custom Script Extension to install IIS and configure basic website
Add-AzVmssExtension -VirtualMachineScaleSet $vmss `
-Name "customScript" `
-Publisher "Microsoft.Compute" `
-Type "CustomScriptExtension" `
-Setting $publicSettings
# Update the scale set and apply the Custom Script Extension to the VM instances
Update-AzVmss `
-Name "myScaleSet" `
-VirtualMachineScaleSet $vmss
Permitir tráfico a la aplicación

Para permitir el acceso a la aplicación web básica, cree un grupo de seguridad de red con New -
AzNetworkSecurityRuleConfig y New -AzNetworkSecurityGroup. Para más información, consulte Redes para
conjuntos de escalado de máquinas virtuales de Azure.
# Get information about the scale set

$vmss = Get-AzVmss `
#Create a rule to allow traffic over port 80

$nsgFrontendRule = New-AzNetworkSecurityRuleConfig `
-Name myFrontendNSGRule `
-Protocol Tcp `
-Direction Inbound `
-Priority 200 `
-SourceAddressPrefix * `
-SourcePortRange * `
-DestinationAddressPrefix * `
-DestinationPortRange 80 `
-Access Allow
#Create a network security group and associate it with the rule

$nsgFrontend = New-AzNetworkSecurityGroup `
-Location EastUS `
-Name myFrontendNSG `
-SecurityRules $nsgFrontendRule
$vnet = Get-AzVirtualNetwork `
-Name myVnet
$frontendSubnet = $vnet.Subnets[0]
$frontendSubnetConfig = Set-AzVirtualNetworkSubnetConfig `
-VirtualNetwork $vnet `
-Name mySubnet `
-AddressPrefix $frontendSubnet.AddressPrefix `
-NetworkSecurityGroup $nsgFrontend
Set-AzVirtualNetwork -VirtualNetwork $vnet
# Update the scale set and apply the Custom Script Extension to the VM instances
Update-AzVmss `
Prueba del conjunto de escalado

Para ver el conjunto de escalado en acción, obtenga la dirección IP pública del equilibrador de carga con Get-
AzPublicIPAddress. En el ejemplo siguiente se muestra la dirección IP de myPublicIP que se ha creado como parte
del conjunto de escalado:
-Name "myPublicIPAddress" | select IpAddress
Escriba la dirección IP pública en un explorador web. Se muestra la aplicación web, incluido el nombre de host de
la máquina virtual a la que el equilibrador de carga distribuye el tráfico:
Para ver el conjunto de escalado en funcionamiento, realice una actualización forzada del explorador web para ver
cómo el equilibrador de carga distribuye el tráfico entre las máquinas virtuales del conjunto de escalado que
ejecutan la aplicación.
Tareas de administración
Durante el ciclo de vida del conjunto de escalado, debe ejecutar una o varias tareas de administración. Además,
puede crear scripts para automatizar varias tareas de ciclo de vida. Azure PowerShell proporciona una forma
rápida de realizar esas tareas. A continuación, presentamos algunas tareas comunes.
Visualización de máquinas virtuales en un conjunto de escalado
Para ver una lista de las instancias de máquina virtual en un conjunto de escalado, use Get-AzVmssVM de la forma
siguiente:
Get-AzVmssVM `
La salida del ejemplo siguiente muestra dos instancias de máquina virtual del conjunto de escalado:
ResourceGroupName Name Location Sku InstanceID ProvisioningState

----------------- ---- -------- --- ---------- -----------------
MYRESOURCEGROUPSCALESET myScaleSet_0 eastus Standard_DS1_v2 0 Succeeded
MYRESOURCEGROUPSCALESET myScaleSet_1 eastus Standard_DS1_v2 1 Succeeded
Para ver información adicional acerca de una instancia específica de la máquina virtual, agregue el parámetro
-InstanceId a Get-AzVmssVM. En el ejemplo siguiente, se ve información sobre la instancia de máquina virtual 1:
Get-AzVmssVM `
-InstanceId "1"
Aumento o disminución de instancias de máquina virtual

Para ver el número de instancias que tiene actualmente en un conjunto de escalado, use Get-AzVmss y realice
consultas a sku.capacity:
Get-AzVmss -ResourceGroupName "myResourceGroupScaleSet" `
-VMScaleSetName "myScaleSet" | `
Select -ExpandProperty Sku
A continuación, puede aumentar o reducir manualmente el número de máquinas virtuales del conjunto de
escalado con Update-AzVmss. En el ejemplo siguiente se establece el número de máquinas virtuales en el conjunto
de escalado en 3:
# Get current scale set

$scaleset = Get-AzVmss `
# Set and update the capacity of your scale set

$scaleset.sku.capacity = 3
Update-AzVmss -ResourceGroupName "myResourceGroupScaleSet" `
-VirtualMachineScaleSet $scaleset
Se tarda unos minutos en actualizar el número especificado de instancias en el conjunto de escalado.

Configuración de reglas de escalado automático
En lugar de escalar manualmente el número de instancias en el conjunto de escalado, defina reglas de escalado
automático. Estas reglas supervisan las instancias en el conjunto de escalado y responden según corresponda,
basándose en las métricas y los umbrales que defina. En el ejemplo siguiente se escala horizontalmente el número
de instancias en uno cuando la carga de CPU media es mayor que el 60 % durante un período de cinco minutos. Si
la carga de CPU media se sitúa por debajo del 30 % durante un período de cinco minutos, las instancias se reducen
horizontalmente en una instancia:
# Define your scale set information
$mySubscriptionId = (Get-AzSubscription)[0].Id
$myResourceGroup = "myResourceGroupScaleSet"
$myScaleSet = "myScaleSet"
$myLocation = "East US"
$myScaleSetId = (Get-AzVmss -ResourceGroupName $myResourceGroup -VMScaleSetName $myScaleSet).Id
# Create a scale up rule to increase the number instances after 60% average CPU usage exceeded for a 5-minute
period
$myRuleScaleUp = New-AzAutoscaleRule `
-MetricName "Percentage CPU" `
-MetricResourceId $myScaleSetId `
-Operator GreaterThan `
-MetricStatistic Average `
-Threshold 60 `
-TimeGrain 00:01:00 `
-TimeWindow 00:05:00 `
-ScaleActionCooldown 00:05:00 `
-ScaleActionDirection Increase `
-ScaleActionValue 1
# Create a scale down rule to decrease the number of instances after 30% average CPU usage over a 5-minute
period
$myRuleScaleDown = New-AzAutoscaleRule `
-MetricName "Percentage CPU" `
-MetricResourceId $myScaleSetId `
-Operator LessThan `
-MetricStatistic Average `
-Threshold 30 `
-TimeGrain 00:01:00 `
-TimeWindow 00:05:00 `
-ScaleActionCooldown 00:05:00 `
-ScaleActionDirection Decrease `
-ScaleActionValue 1
# Create a scale profile with your scale up and scale down rules
$myScaleProfile = New-AzAutoscaleProfile `
-DefaultCapacity 2 `
-MaximumCapacity 10 `
-MinimumCapacity 2 `
-Rule $myRuleScaleUp,$myRuleScaleDown `
-Name "autoprofile"
# Apply the autoscale rules

Add-AzAutoscaleSetting `
-Location $myLocation `
-Name "autosetting" `
-ResourceGroup $myResourceGroup `
-TargetResourceId $myScaleSetId `
-AutoscaleProfile $myScaleProfile
Para más información de diseño sobre el uso del escalado automático, consulte los procedimientos recomendados
de escalado automático.
Pasos siguientes
En este tutorial, ha creado un conjunto de escalado de máquinas virtuales. Ha aprendido a:
Usar la extensión de script personalizada para definir un sitio IIS para escalar
Crear un equilibrador de carga para el conjunto de escalado
Crear un conjunto de escalado de máquinas virtuales
Aumentar o disminuir el número de instancias en un conjunto de escalado
Crear reglas de escalado automático
Pase al siguiente tutorial para obtener más información sobre el concepto de equilibrio de carga de las máquinas
virtuales.
Load balance virtual machines (Equilibrio de carga de máquinas virtuales)
Tutorial: Equilibrio de carga de máquinas virtuales
Windows en Azure para crear una aplicación de alta
disponibilidad con Azure PowerShell
El equilibrio de carga proporciona un mayor nivel de disponibilidad al distribuir las solicitudes entrantes entre
varias máquinas virtuales. En este tutorial, aprenderá sobre los distintos componentes de Azure Load Balancer
que distribuyen el tráfico y proporcionan una alta disponibilidad. Aprenderá a:
Creación de un equilibrador de carga de Azure
Creación del sondeo de estado de un equilibrador de carga
Crear reglas de tráfico del equilibrador de carga
Usar la extensión de script personalizada para crear un sitio IIS básico
Crear máquinas virtuales y conectarlas a un equilibrador de carga
Ver un equilibrador de carga en acción
Agregar y quitar las máquinas virtuales de un equilibrador de carga
Información general sobre Azure Load Balancer

Un equilibrador de carga de Azure es un equilibrador de carga de nivel 4 (TCP, UDP ) que proporciona una alta
disponibilidad mediante la distribución del tráfico entrante entre máquinas virtuales con un estado correcto. Un
sondeo de estado de equilibrador de carga supervisa un puerto determinado en cada máquina virtual y solo
distribuye tráfico a una máquina virtual operativa.
Se define una configuración de IP de front-end que contiene una o varias direcciones IP públicas. Esta
configuración de IP de front-end permite que el equilibrador de carga y las aplicaciones sean accesibles a través
de Internet.
Las máquinas virtuales se conectarán a un equilibrador de carga mediante su tarjeta de interfaz de red (NIC )
virtual. Para distribuir el tráfico a las máquinas virtuales, un grupo de direcciones de back-end contiene las
direcciones IP de las tarjetas de interfaz de red (NIC ) virtual conectadas al equilibrador de carga.
Para controlar el flujo de tráfico, se definen reglas de equilibrador de carga para determinados puertos y
protocolos que se asignan a las máquinas virtuales.

Creación del equilibrador de carga de Azure

En esta sección se detalla cómo se puede crear y configurar cada componente del equilibrador de carga. Para
poder crear el equilibrador de carga, cree un grupo de recursos con New -AzResourceGroup. En el ejemplo
siguiente, se crea un grupo de recursos denominado myResourceGroupLoadBalancer en la ubicación EastUS:
-ResourceGroupName "myResourceGroupLoadBalancer" `
-Location "EastUS"
Crear una dirección IP pública

Para obtener acceso a la aplicación en Internet, necesita una dirección IP pública para el equilibrador de carga.
Cree una dirección IP pública con New -AzPublicIpAddress. En el ejemplo siguiente se crea una dirección IP
pública denominada myPublicIP en el grupo de recursos myResourceGroupLoadBalancer:
$publicIP = New-AzPublicIpAddress `
-AllocationMethod "Static" `
-Name "myPublicIP"
Creación de un equilibrador de carga

Cree un grupo de direcciones IP de front-end con New -AzLoadBalancerFrontendIpConfig. En el ejemplo
siguiente se crea un grupo de direcciones IP de front-end llamado myFrontEndPool y se asocia la dirección
myPublicIP:
$frontendIP = New-AzLoadBalancerFrontendIpConfig `
-Name "myFrontEndPool" `
-PublicIpAddress $publicIP
Cree un grupo de direcciones de back-end con New -AzLoadBalancerBackendAddressPoolConfig. En el resto de

los pasos las máquinas virtuales se conectan a este grupo back-end. En el siguiente ejemplo se crea un grupo de
direcciones de back-end denominado myBackEndPool:
$backendPool = New-AzLoadBalancerBackendAddressPoolConfig `
-Name "myBackEndPool"
Ahora, cree el equilibrador de carga con New -AzLoadBalancer. En el ejemplo siguiente se crea un equilibrador de
carga llamado myLoadBalancer mediante los grupos de direcciones IP de front-end y back-end creados en los
pasos anteriores:
$lb = New-AzLoadBalancer `
-Name "myLoadBalancer" `
-FrontendIpConfiguration $frontendIP `
-BackendAddressPool $backendPool
Creación de un sondeo de estado

Para permitir que el equilibrador de carga supervise el estado de la aplicación, utilice un sondeo de estado. El
sondeo de estado agrega o quita de forma dinámica las máquinas virtuales de la rotación del equilibrador de
carga en base a su respuesta a las comprobaciones de estado. De forma predeterminada, una máquina virtual se
quita de la distribución del equilibrador de carga después de dos errores consecutivos en un intervalo de 15
segundos. Cree un sondeo de estado en función de un protocolo o una página de comprobación de
mantenimiento específica para la aplicación.
En el ejemplo siguiente se crea un sondeo de TCP. También se pueden crear sondeos HTTP personalizados para
comprobaciones de estado más específicas. Al usar un sondeo HTTP personalizado, debe crear la página de
comprobación de estado, por ejemplo healthcheck.aspx. El sondeo debe devolver una respuesta HTTP 200 OK
para que el equilibrador de carga mantenga el host en rotación.
Para crear un sondeo de estado TCP, se usa Add-AzLoadBalancerProbeConfig. En el ejemplo siguiente se crea un
sondeo de estado llamado myHealthProbe que supervisa cada máquina virtual en el puerto TCP 80:
Add-AzLoadBalancerProbeConfig `
-Name "myHealthProbe" `
-LoadBalancer $lb `
-Protocol tcp `
-Port 80 `
-IntervalInSeconds 15 `
-ProbeCount 2
Para aplicar el sondeo de estado, actualice el equilibrador de carga con Set-AzLoadBalancer:
Set-AzLoadBalancer -LoadBalancer $lb
Creación de una regla de equilibrador de carga

Las reglas de equilibrador de carga se utilizan para definir cómo se distribuye el tráfico a las máquinas virtuales.
Se define la configuración de IP front-end para el tráfico entrante y el grupo IP de back-end para recibir el tráfico,
junto con el puerto de origen y destino requeridos. Para asegurarse de que solo las máquinas virtuales correctas
reciban tráfico, también hay que definir el sondeo de estado que se va usar.
Cree una regla del equilibrador de carga con Add-AzLoadBalancerRuleConfig. En el ejemplo siguiente se crea
una regla del equilibrador de carga llamada myLoadBalancerRule y se equilibra el tráfico en el puerto TCP 80:
$probe = Get-AzLoadBalancerProbeConfig -LoadBalancer $lb -Name "myHealthProbe"
Add-AzLoadBalancerRuleConfig `
-Name "myLoadBalancerRule" `
-LoadBalancer $lb `
-FrontendIpConfiguration $lb.FrontendIpConfigurations[0] `
-BackendAddressPool $lb.BackendAddressPools[0] `
-Protocol Tcp `
-FrontendPort 80 `
-BackendPort 80 `
-Probe $probe
Actualice el equilibrador de carga con Set-AzLoadBalancer:
Set-AzLoadBalancer -LoadBalancer $lb
Configurar la red virtual

Antes de implementar algunas máquinas virtuales y poder probar el equilibrador, cree los recursos de red virtual
auxiliares. Para más información sobre las redes virtuales, consulte el tutorial Administración de Azure Virtual
Networks.
Crear recursos de red
Cree una red virtual con New -AzVirtualNetwork. En el ejemplo siguiente se crea una red virtual denominada con
una subred llamada myVnet con mySubnet:
# Create subnet config
$subnetConfig = New-AzVirtualNetworkSubnetConfig `
-Name "mySubnet" `
-AddressPrefix 192.168.1.0/24
# Create the virtual network

$vnet = New-AzVirtualNetwork `
-Name "myVnet" `
-AddressPrefix 192.168.0.0/16 `
-Subnet $subnetConfig
Las NIC virtuales se crean con New -AzNetworkInterface. En el ejemplo siguiente se crean tres NIC. (Una NIC
virtual para cada máquina virtual que cree para la aplicación en los pasos siguientes). Puede crear NIC virtuales y
máquinas virtuales adicionales en cualquier momento y agregarlas al equilibrador de carga:
for ($i=1; $i -le 3; $i++)

{
New-AzNetworkInterface `
-Name myVM$i `
-Subnet $vnet.Subnets[0] `
-LoadBalancerBackendAddressPool $lb.BackendAddressPools[0]
}
Crear máquinas virtuales

Para mejorar la alta disponibilidad de la aplicación, coloque las máquinas virtuales en un conjunto de
disponibilidad.
Cree un conjunto de disponibilidad con New -AzAvailabilitySet. En el ejemplo siguiente se crea un conjunto de
disponibilidad denominado myAvailabilitySet:
$availabilitySet = New-AzAvailabilitySet `
-Name "myAvailabilitySet" `
-Sku aligned `
-PlatformUpdateDomainCount 2
Establezca un nombre de usuario de administrador y una contraseña para las máquinas virtuales con Get-
Credential:
Ahora puede crear las máquinas virtuales con New -AzVM. En el siguiente ejemplo se crean tres máquinas
virtuales y los componentes de red virtual necesarios, si aún no existen:
for ($i=1; $i -le 3; $i++)
{
New-AzVm `
-Name "myVM$i" `
-OpenPorts 80 `
-Credential $cred `
-AsJob
}
El parámetro -AsJob crea la máquina virtual como tarea en segundo plano, por lo que PowerShell solicita la
vuelta. Puede ver detalles de trabajos en segundo plano con el cmdlet Job . Se tarda unos minutos en crear y
configurar las tres máquinas virtuales.
Instalar IIS con la extensión de script personalizado
En un tutorial anterior sobre Cómo personalizar una máquina virtual de Windows, aprendió a automatizar la
personalización de máquinas virtuales con la extensión de script personalizado para Windows. Puede usar el
mismo enfoque para instalar y configurar IIS en las máquinas virtuales.
Use Set-AzVMExtension para instalar la extensión de script personalizado. La extensión ejecuta
powershell Add-WindowsFeature Web-Server para instalar el servidor web de IIS y después actualiza la página
Default.htm para mostrar el nombre de host de la máquina virtual:
for ($i=1; $i -le 3; $i++)

{
Set-AzVMExtension `
-VMName myVM$i `
-SettingString '{"commandToExecute":"powershell Add-WindowsFeature Web-Server; powershell Add-Content -
Path \"C:\\inetpub\\wwwroot\\Default.htm\" -Value $($env:computername)"}' `
-Location EastUS
}
Prueba del equilibrador de carga

Obtenga la dirección IP pública del equilibrador de carga con Get-AzPublicIPAddress. En el ejemplo siguiente se
obtiene la dirección IP de myPublicIP que se ha creado anteriormente:
-Name "myPublicIP" | select IpAddress
A continuación, puede escribir la dirección IP pública en un explorador web. Se muestra el sitio web, incluido el
nombre de host de la máquina virtual a la que el equilibrador de carga distribuye el tráfico como en el ejemplo
siguiente:
Para ver cómo el equilibrador de carga distribuye el tráfico entre las tres máquinas virtuales que ejecutan la
aplicación, puede realizar una actualización forzada del explorador web.
Agregar y quitar máquinas virtuales

Puede que tenga que realizar labores de mantenimiento de las máquinas virtuales que ejecutan la aplicación,
como la instalación de actualizaciones del sistema operativo. Para gestionar un aumento de tráfico a la aplicación,
tiene que agregar más máquinas virtuales. Esta sección le muestra cómo quitar o agregar una máquina virtual
desde el equilibrador de carga.
Eliminación de una máquina virtual del equilibrador de carga
Obtenga la tarjeta de interfaz de red con Get-AzNetworkInterface y después establezca la propiedad
LoadBalancerBackendAddressPools de la NIC virtual en $null. Por último, actualice la NIC virtual:
$nic = Get-AzNetworkInterface `
-Name "myVM2"
$nic.Ipconfigurations[0].LoadBalancerBackendAddressPools=$null
Set-AzNetworkInterface -NetworkInterface $nic
Para ver cómo el equilibrador de carga distribuye el tráfico entre las dos máquinas virtuales que quedan
ejecutando la aplicación, puede realizar una actualización forzada del explorador web. Ahora puede realizar tareas
de mantenimiento en la máquina virtual, como instalar actualizaciones del sistema operativo o realizar un reinicio
de máquina virtual.
Incorporación de una máquina virtual al equilibrador de carga
Después de realizar el mantenimiento de la máquina virtual o si necesita expandir la capacidad, establezca la
propiedad LoadBalancerBackendAddressPools de la NIC virtual en el elemento BackendAddressPool de Get-
AzLoadBalancer:
Obtención del equilibrador de carga:
$lb = Get-AzLoadBalancer `
-ResourceGroupName myResourceGroupLoadBalancer `
-Name myLoadBalancer
$nic.IpConfigurations[0].LoadBalancerBackendAddressPools=$lb.BackendAddressPools[0]
Set-AzNetworkInterface -NetworkInterface $nic
Pasos siguientes
En este tutorial, ha creado un equilibrador de carga y conectó máquinas virtuales a él. Ha aprendido a:
Creación de un equilibrador de carga de Azure
Creación del sondeo de estado de un equilibrador de carga
Crear reglas de tráfico del equilibrador de carga
Usar la extensión de script personalizada para crear un sitio IIS básico
Crear máquinas virtuales y conectarlas a un equilibrador de carga
Ver un equilibrador de carga en acción
Agregar y quitar las máquinas virtuales de un equilibrador de carga
Avance al siguiente tutorial para aprender a administrar redes de máquinas virtuales.
Administración de máquinas y redes virtuales
Tutorial: Creación y administración de redes virtuales
de Azure para máquinas virtuales Windows con
Azure PowerShell
Las máquinas virtuales de Azure utilizan las redes de Azure para la comunicación de red interna y externa. Este
tutorial le guía a través de la implementación de dos máquinas virtuales y la configuración de redes de Azure para
estas máquinas virtuales. Se da por supuesto que en los ejemplos de este tutorial las máquinas virtuales
hospedan una aplicación web con un back-end de base de datos, sin embargo, no se implementa ninguna
aplicación en el tutorial. En este tutorial, aprenderá a:
Creación de una red virtual y una subred
Crear una máquina virtual de front-end
Protegen el tráfico de red.
Creación de la máquina virtual de "back-end"
Introducción a las redes de máquinas virtuales

Las redes virtuales de Azure habilitan las conexiones de red seguras entre máquinas virtuales, Internet y otros
servicios de Azure SQL Database. Las redes virtuales se dividen en segmentos lógicos llamados subredes. Las
subredes se utilizan para controlar el flujo de red y como límite de seguridad. La implementación de una máquina
virtual incluye, por lo general, una interfaz de red virtual, que está conectada a una subred.
Al completar este tutorial, podrá ver que se crearon los siguientes recursos:
myVNet: red virtual que las máquinas virtuales usan para comunicarse entre sí y con Internet.
myFrontendSubnet: subred de myVNet que usan los recursos de front-end.
myPublicIPAddress: dirección IP pública que se usa para tener acceso a myFrontendVM desde Internet.
myFrontendNic: interfaz de red que usa myFrontendVM para comunicarse con myBackendVM.
myFrontendVM: máquina virtual que se usa para la comunicación entre Internet y myBackendVM.
myBackendNSG: grupo de seguridad de red que controla la comunicación entre myFrontendVM y
myBackendVM.
myBackendSubnet: subred asociada a myBackendNSG y que usan los recursos de back-end.
myBackendNic: interfaz de red que usa myBackendVM para comunicarse con myFrontendVM.
myBackendVM: máquina virtual que usa el puerto 1433 para comunicarse con myFrontendVM.

Creación de una subred

Para este tutorial, se crea una única red virtual con dos subredes: una subred de front-end para hospedar una
aplicación web y una subred de back-end para hospedar un servidor de bases de datos.
Antes de poder crear una red virtual, debe crear un grupo de recursos mediante New -AzResourceGroup. En el
ejemplo siguiente, se crea un grupo de recursos denominado myRGNetwork en la ubicación EastUS:
New-AzResourceGroup -ResourceGroupName myRGNetwork -Location EastUS
Cree una configuración de subred llamada myFrontendSubnet mediante New -AzVirtualNetworkSubnetConfig:
$frontendSubnet = New-AzVirtualNetworkSubnetConfig `
-Name myFrontendSubnet `
Además, debe crear una configuración de subred llamada myBackendSubnet:
$backendSubnet = New-AzVirtualNetworkSubnetConfig `
-Name myBackendSubnet `

Cree una red virtual denominada myVNet mediante myFrontendSubnet y myBackendSubnet mediante New -
AzVirtualNetwork:
-ResourceGroupName myRGNetwork `
-Location EastUS `
-Name myVNet `
-Subnet $frontendSubnet, $backendSubnet
Entonces, se ha creado una red y se ha segmentado en dos subredes, una para servicios front-end y otra para
servicios back-end. En la siguiente sección, se crean máquinas virtuales y se conectan a estas subredes.

Una dirección IP pública permite que los recursos de Azure estén accesibles en Internet. El método de asignación
de la dirección IP pública se puede configurar como dinámico o estático. De forma predeterminada, la dirección IP
pública se asigna dinámicamente. Las direcciones IP dinámicas se liberan al desasignar una máquina virtual. Este
comportamiento hace que la dirección IP cambie durante cualquier operación que incluya una desasignación de
máquina virtual.
El método de asignación se puede establecer en estático, lo que garantiza que la dirección IP siga asignada a una
máquina virtual, incluso durante un estado de desasignación. Si usa una dirección IP estática, no se puede
especificar la propia dirección IP, sino que se asigna desde un grupo de direcciones disponibles.
Cree una dirección IP pública denominada myPublicIPAddress mediante New -AzPublicIpAddress:
$pip = New-AzPublicIpAddress `
-Location EastUS `
-AllocationMethod Dynamic `
-Name myPublicIPAddress
Puede cambiar el parámetro -AllocationMethod a Static , para asignar una dirección IP pública estática.

Para que una máquina virtual se comunique en una red virtual, debe tener una interfaz de red virtual (NIC ). Cree
una NIC con New -AzNetworkInterface:
$frontendNic = New-AzNetworkInterface `
-Location EastUS `
-Name myFrontend `
-SubnetId $vnet.Subnets[0].Id `
-PublicIpAddressId $pip.Id
virtual con Get-Credential. Use estas credenciales para conectarse a la máquina virtual en pasos adicionales:
Cree máquinas virtuales mediante New -AzVM.
New-AzVM `
-Credential $cred `
-Name myFrontend `
-PublicIpAddressName myPublicIPAddress `
-Size Standard_D1 `
-SubnetName myFrontendSubnet `
-VirtualNetworkName myVNet

Un grupo de seguridad de red (NSG ) contiene una lista de reglas de seguridad que permiten o deniegan el tráfico
de red a recursos conectados a Azure Virtual Network (VNet). Los NSG se pueden asociar a subredes o a
interfaces de red individuales. Cuando un NSG está asociado a una interfaz de red, se aplica solo a la máquina
virtual asociada. Cuando un grupo de seguridad de red está asociado a una subred, las reglas se aplican a todos
los recursos conectados a la subred.
Reglas del grupo de seguridad de red
Las reglas de NSG definen puertos de redes a través de los que se permite o deniega el tráfico. Las reglas pueden
incluir intervalos de direcciones IP de origen y destino para que el tráfico se controle entre sistemas o subredes
específicos. Las reglas de NSG también incluyen una prioridad (entre 1 y 4096). Las reglas se evalúan por orden
de prioridad. Una regla con una prioridad de 100 se evalúa antes que una regla con prioridad de 200.
Todos los grupos de seguridad de red contienen un conjunto de reglas predeterminadas. Las reglas
predeterminadas no se pueden eliminar, pero dado que tienen asignada la mínima prioridad, pueden
reemplazarse por las reglas que cree.
Red virtual: el tráfico que se origina y termina en una red virtual se permite en las direcciones tanto de
entrada como de salida.
Internet: se permite el tráfico saliente pero se bloquea el entrante.
Equilibrador de carga: se permite que el equilibrador de carga de Azure sondee el estado de las máquinas
virtuales y las instancias de rol. Si no va a usar un conjunto con equilibrio de carga, puede invalidar esta regla.
Creación de grupos de seguridad de red
Cree una regla de entrada denominada myFrontendNSGRule para permitir el tráfico web entrante en
myFrontendVM mediante New -AzNetworkSecurityRuleConfig:
$nsgFrontendRule = New-AzNetworkSecurityRuleConfig `
-Name myFrontendNSGRule `
-Protocol Tcp `
-Priority 200 `
-Access Allow
Puede limitar el tráfico interno a myBackendVM solo desde myFrontendVM creando un NSG para la subred de
"back-end". En el ejemplo siguiente, se crea una regla NSG denominada myBackendNSGRule:
$nsgBackendRule = New-AzNetworkSecurityRuleConfig `
-Name myBackendNSGRule `
-Protocol Tcp `
-Priority 100 `
-SourceAddressPrefix 10.0.0.0/24 `
-Access Allow
Agregue un nuevo grupo de seguridad de red denominado myFrontendNSG mediante New -

AzNetworkSecurityGroup:
$nsgFrontend = New-AzNetworkSecurityGroup `
-Location EastUS `
-Name myFrontendNSG `
-SecurityRules $nsgFrontendRule
Agregue un nuevo grupo de seguridad de red denominado myBackendNSG mediante New -

AzNetworkSecurityGroup:
$nsgBackend = New-AzNetworkSecurityGroup `
-Location EastUS `
-Name myBackendNSG `
-SecurityRules $nsgBackendRule
Agregue los grupos de seguridad de red a las subredes:

-Name myVNet
$frontendSubnet = $vnet.Subnets[0]
$backendSubnet = $vnet.Subnets[1]
$frontendSubnetConfig = Set-AzVirtualNetworkSubnetConfig `
-Name myFrontendSubnet `
-AddressPrefix $frontendSubnet.AddressPrefix `
-NetworkSecurityGroup $nsgFrontend
$backendSubnetConfig = Set-AzVirtualNetworkSubnetConfig `
-Name myBackendSubnet `
-AddressPrefix $backendSubnet.AddressPrefix `
-NetworkSecurityGroup $nsgBackend
Crear una máquina virtual de back-end

La manera más fácil de crear la máquina virtual de back-end que se detalla en este tutorial es usar una imagen de
SQL Server. Con este tutorial solo se crea la máquina virtual con el servidor de base de datos, pero no se
proporciona información del acceso a la base de datos.
Creación de myBackendNic:
$backendNic = New-AzNetworkInterface `
-Location EastUS `
-Name myBackend `
-SubnetId $vnet.Subnets[1].Id
Creación de myBackendVM.
New-AzVM `
-Credential $cred `
-Name myBackend `
-ImageName "MicrosoftSQLServer:SQL2016SP1-WS2016:Enterprise:latest" `
-SubnetName MyBackendSubnet `
-VirtualNetworkName myVNet
La imagen de este ejemplo tiene instalado SQL Server, pero no se usa en este tutorial. Se incluye para mostrar
cómo se pueden configurar una máquina virtual para controlar el tráfico de web y otra para controlar la
administración de bases de datos.
Pasos siguientes
En este tutorial, ha creado y protegido redes de Azure cuando están relacionadas con máquinas virtuales.
Creación de una red virtual y una subred
Crear una máquina virtual de back-end
Prosiga con el siguiente tutorial para aprender a supervisar la protección de datos en máquinas virtuales
mediante Azure Backup.
Copia de seguridad de máquinas virtuales Windows en Azure
Tutorial: Realización de copias de seguridad y
restauración de archivos en máquinas virtuales
Windows en Azure
Para proteger sus datos realice copias de seguridad a intervalos regulares. Azure Backup crea puntos de
recuperación que se almacenan en almacenes de recuperación con redundancia geográfica. Cuando se realiza una
restauración desde un punto de recuperación, se puede restaurar toda la máquina virtual o determinados
archivos. En este artículo se explica cómo restaurar un único archivo en una máquina virtual que ejecuta Windows
Server e IIS. Si aún no tiene una máquina virtual que pueda usar, puede crear una mediante la guía de inicio
rápido de Windows. En este tutorial, aprenderá a:
Crear una copia de seguridad de una máquina virtual.
Programar una copia de seguridad diaria.
Restaurar un archivo desde una copia de seguridad.
Introducción a Backup
Cuando el servicio Azure Backup inicia una copia de seguridad, desencadena la extensión de copia de seguridad
para que tome una instantánea de un momento dado. El servicio Azure Backup usa la extensión VMSnapshot. La
extensión se instala cuando se realiza la primera copia de seguridad de la máquina virtual, en caso de que esta
esté en ejecución. Si no se está ejecutando la máquina virtual, el servicio Azure Backup toma una instantánea del
almacenamiento subyacente (ya que no se produce ninguna escritura de la aplicación mientras se detiene la
máquina virtual).
Cuando se toma una instantánea de las máquinas virtuales de Windows, el servicio Azure Backup se coordina con
el servicio de instantáneas de volumen (VSS ) para obtener una instantánea coherente de los discos de la máquina
virtual. Después de que el servicio Azure Backup toma la instantánea, se transfieren los datos al almacén. Para que
el proceso resulte más eficaz, el servicio identifica y transfiere únicamente los bloques de datos que han cambiado
desde la última copia de seguridad.
Cuando finaliza la transferencia de datos, se elimina la instantánea y se crea un punto de recuperación.
Creación de una copia de seguridad

Cree una copia de seguridad diaria programada simple en un almacén de Recovery Services.
1. Inicie sesión en el Azure Portal.
2. En el menú de la izquierda, haga clic en Máquinas virtuales.
3. En la lista, seleccione la máquina virtual de la que quiere realizar una copia de seguridad.
4. En la hoja de la máquina virtual, en la sección Operaciones, haga clic en Copia de seguridad. Se abre la
hoja Habilitar copia de seguridad.
5. En Almacén de Recovery Services, haga clic en Create new (Crear nuevo) y especifique el nombre del
nuevo almacén. Se crea un almacén en la misma ubicación y el mismo grupo de recursos en que se
encuentra la máquina virtual.
6. En Elegir directiva de copia de seguridad, mantenga el valor predeterminado DailyPolicy (nuevo) y,
después, haga clic en Habilitar copia de seguridad.
7. Para crear un punto de recuperación inicial, en la hoja Copia de seguridad haga clic en Realizar copia de
seguridad ahora.
8. En la hoja Realizar copia de seguridad ahora, haga clic en el icono del calendario, use el control de
calendario para elegir el tiempo que se va a conservar el punto de restauración y haga clic en Aceptar.
9. En la hoja Copia de seguridad de la máquina virtual, verá el número de puntos de restauración
completos.
La primera copia de seguridad tarda aproximadamente 20 minutos. Cuando la copia de seguridad finalice, pase a
la parte siguiente de este tutorial.
Recuperación de un archivo
Si accidentalmente elimina o realiza cambios en un archivo, puede usar Recuperación de archivos para recuperar
el archivo del almacén de Backup. Recuperación de archivos usa un script que se ejecuta en la máquina virtual
para montar el punto de recuperación como unidad local. Estas unidades permanecen montadas durante 12 horas
para que pueda copiar archivos desde el punto de recuperación y restaurarlos en la máquina virtual.
En este ejemplo, se muestra cómo recuperar el archivo de imagen que se usa en la página web predeterminada de
IIS.
1. Abra un explorador y conéctese a la dirección IP de la máquina virtual para mostrar la página
predeterminada de IIS.
2. Conéctese a la máquina virtual.
3. En la máquina virtual, abra el Explorador de archivos, vaya a \inetpub\wwwroot y elimine el archivo
iisstart.png.
4. En el equipo local, actualice el explorador para ver que la imagen en la página predeterminada de IIS ha
desaparecido.
5. En el equipo local, abra una nueva pestaña y vaya a Azure Portal.

6. En el menú de la izquierda, seleccione Máquinas virtuales y seleccione la máquina virtual de la lista.
7. En la hoja de la máquina virtual, en la sección Operaciones, haga clic en Copia de seguridad. Se abre la
hoja Copia de seguridad.
8. En el menú de la parte superior de la hoja, seleccione Recuperación de archivos. Se abrirá la hoja
Recuperación de archivos.
9. En Paso 1: Seleccionar punto de recuperación, seleccione un punto de recuperación en la lista
desplegable.
10. En Paso 2: Descargar script para examinar y recuperar archivos, haga clic en el botón Descargar
ejecutable. Copie la contraseña del archivo y guárdela en algún lugar seguro.
11. En el equipo local, abra el Explorador de archivos, vaya a la carpeta Descargas y copie el archivo .exe
descargado. El nombre de archivo lleva delante el nombre de su máquina virtual.
12. En la máquina virtual (mediante la conexión RDP ), pegue el archivo .exe en el escritorio de la máquina
virtual.
13. Vaya al escritorio de la máquina virtual y haga doble clic en el archivo .exe. Se iniciará un símbolo del
sistema. El programa monta el punto de recuperación como un recurso compartido de archivos al que se
puede acceder. Cuando se termine de crear el recurso compartido, escriba q para cerrar el símbolo del
sistema.
14. En la máquina virtual, abra el Explorador de archivos y vaya a la letra de unidad que se usó para el
recurso compartido de archivos.
15. Vaya a \inetpub\wwwroot, copie iisstart.png del recurso compartido de archivos y péguelo en
\inetpub\wwwroot. Por ejemplo, copie F:\inetpub\wwwroot\iisstart.png y péguelo en c:\inetpub\wwwroot
para recuperar el archivo.
16. En el equipo local, abra la pestaña del explorador en el que está conectado a la dirección IP de la máquina
virtual que muestra la página predeterminada de IIS. Presione CTRL + F5 para actualizar la página del
explorador. Ahora debería ver que la imagen se ha restaurado.
17. En el equipo local, vuelva a la pestaña del explorador de Azure Portal y, en Paso 3: Desmontar los discos
después de la recuperación, haga clic en el botón Desmontar discos. Si olvida realizar este paso, la
conexión al punto de montaje se cierra automáticamente al cabo de 12 horas. A las 12 horas, es preciso que
descargue un script nuevo para crear un punto de montaje.
Pasos siguientes
En este tutorial aprendió lo siguiente:
Crear una copia de seguridad de una máquina virtual.
Programar una copia de seguridad diaria.
Restaurar un archivo desde una copia de seguridad.
En el siguiente tutorial se explica cómo supervisar máquinas virtuales.
Control de máquinas virtuales
Tutorial: Información acerca de la administración de
máquinas virtuales Windows con Azure PowerShell
Al implementar recursos en Azure, dispone de una enorme flexibilidad a la hora de decidir qué tipos de recursos
implementar, dónde se encuentran y cómo configurarlos. Sin embargo, esa flexibilidad puede abrirle a más
opciones que le gustaría permitir en su organización. Cuando piensa en implementar recursos en Azure, tal vez se
pregunte:
¿Cómo puedo cumplir los requisitos legales de soberanía de datos en determinados países o regiones?
¿Cómo puedo controlar los costos?
¿Cómo puedo asegurarme de que alguien no modifique por error un sistema importante?
¿Cómo puedo realizar un seguimiento de los costos de los recursos y facturarlos de forma precisa?
En este artículo se da respuesta a esas preguntas. En concreto, puede:

Asignar roles a los usuarios y asignar roles a un ámbito, de forma que los usuarios tengan permiso para realizar
acciones esperadas, pero no más acciones.
Aplicar directivas que recomienden convenciones para los recursos de su suscripción.
Bloquear los recursos que son críticos para el sistema.
Etiquetar recursos para que pueda realizar su seguimiento según los valores que encajan con su organización.
Este artículo se centra en las tareas que se realizan para implementar el sistema de gobernanza. Para obtener una
explicación más amplia de los conceptos, consulte Sistema de gobernanza en Azure.

ejecutarlos.
Descripción del ámbito

Antes de crear cualquier elemento, revisemos el concepto de ámbito. Azure proporciona cuatro niveles de
administración: grupo de administración, suscripción, grupo de recursos y recurso. Los grupos de administración
están en versión preliminar. En la imagen siguiente se muestra un ejemplo de estos niveles:
Aplicará la configuración de administración en cualquiera de estos niveles de ámbito. El nivel que seleccione
determina el grado de amplitud con que se aplica la configuración. Los niveles inferiores heredan la configuración
de los niveles superiores. Al aplicar una configuración a la suscripción, dicha configuración se aplica a todos los
grupos de recursos y recursos de la suscripción. Al aplicar una configuración al grupo de recursos, esa
configuración se aplica al grupo de recursos y a todos sus recursos. Sin embargo, otro grupo de recursos no tiene
esa configuración.
Normalmente, tiene sentido aplicar la configuración crítica en niveles superiores y los requisitos específicos del
proyecto en niveles inferiores. Por ejemplo, quizás quiera asegurarse de que todos los recursos de su organización
se implementan en determinadas regiones. Para lograr este requisito, aplique una directiva a la suscripción que
especifique las ubicaciones permitidas. Cuando otros usuarios de su organización agreguen nuevos grupos de
recursos y recursos, se aplicarán automáticamente las ubicaciones permitidas.
En este tutorial, se aplica toda la configuración de administración a un grupo de recursos para poder quitar
fácilmente esas opciones al finalizar.
Vamos a crear el grupo de recursos.
New-AzResourceGroup -Name myResourceGroup -Location EastUS
Actualmente, el grupo de recursos está vacío.
Control de acceso basado en rol

Desea asegurarse de que los usuarios de una organización tengan el nivel adecuado de acceso a estos recursos.
No desea conceder acceso ilimitado a los usuarios, pero también es necesario garantizar que puedan realizar su
trabajo. El control de acceso basado en rol le permite administrar los usuarios con permiso para completar
acciones específicas en un ámbito.
Para crear y quitar las asignaciones de rol, los usuarios deben tener acceso a
Microsoft.Authorization/roleAssignments/* . Esta acción se concede mediante los roles Propietario o Administrador
de acceso de usuario.
Para administrar las soluciones de máquina virtual, hay tres roles específicos a los recursos, que normalmente
proporcionan el acceso necesario:
Colaborador de la máquina virtual
Colaborador de la red
Colaborador de la cuenta de almacenamiento
En lugar de asignar roles a usuarios individuales, a menudo resulta más fácil usar un grupo de Azure Active
Directory con usuarios que tienen que realizar acciones similares. A continuación, asigne a ese grupo el rol
apropiado. Para este artículo puede usar un grupo existente para administrar la máquina virtual o el portal para
crear un grupo de Azure Active Directory.
Después de crear un grupo o de buscar uno existente, use el comando New -AzRoleAssignment para asignar el
grupo de Azure Active Directory al rol Colaborador de la máquina virtual para el grupo de recursos.
$adgroup = Get-AzADGroup -DisplayName <your-group-name>
New-AzRoleAssignment -ObjectId $adgroup.id `

-RoleDefinitionName "Virtual Machine Contributor"
Si recibe un error que indica Principal <guid> does not exist in the directory (La entidad de seguridad no
existe en el directorio), el nuevo grupo no se ha propagado en Azure Active Directory. Intente ejecutar el comando
de nuevo.
Por lo general, repetirá el proceso para Colaborador de la red y Colaborador de la cuenta de almacenamiento con
el objetivo de asegurarse de que los usuarios se asignan para administrar los recursos implementados. En este
artículo, puede omitir esos pasos.
Azure Policy
Azure Policy ayuda a asegurarse de que todos los recursos de la suscripción satisfacen los estándares corporativos.
La suscripción ya tiene varias definiciones de directiva. Para ver las definiciones de directivas disponibles, use el
comando Get-AzPolicyDefinition:
(Get-AzPolicyDefinition).Properties | Format-Table displayName, policyType
Ve las definiciones de directiva existentes. El tipo de directiva es BuiltIn o Custom. Examine las definiciones para
buscar las que describan una condición que quiera asignar. En este artículo, puede asignar directivas que:
Limite las ubicaciones para todos los recursos.
Limite las SKU para las máquinas virtuales.
Realice auditorías de las máquinas virtuales que no usen discos administrados.
En el siguiente ejemplo, se recuperan tres definiciones de directivas en función del nombre para mostrar. Puede
usar el comando New -AzPolicyAssignment para asignar esas definiciones al grupo de recursos. En algunas
directivas, puede proporcionar los valores de los parámetros para especificar los valores permitidos.
# Values to use for parameters
$locations ="eastus", "eastus2"
$skus = "Standard_DS1_v2", "Standard_E2s_v2"
# Get the resource group

$rg = Get-AzResourceGroup -Name myResourceGroup
# Get policy definitions for allowed locations, allowed SKUs, and auditing VMs that don't use managed disks
$locationDefinition = Get-AzPolicyDefinition | where-object {$_.properties.displayname -eq "Allowed
locations"}
$skuDefinition = Get-AzPolicyDefinition | where-object {$_.properties.displayname -eq "Allowed virtual machine
SKUs"}
$auditDefinition = Get-AzPolicyDefinition | where-object {$_.properties.displayname -eq "Audit VMs that do not
use managed disks"}
# Assign policy for allowed locations

New-AzPolicyAssignment -Name "Set permitted locations" `
-Scope $rg.ResourceId `
-PolicyDefinition $locationDefinition `
-listOfAllowedLocations $locations
# Assign policy for allowed SKUs

New-AzPolicyAssignment -Name "Set permitted VM SKUs" `
-PolicyDefinition $skuDefinition `
-listOfAllowedSKUs $skus
# Assign policy for auditing unmanaged disks

New-AzPolicyAssignment -Name "Audit unmanaged disks" `
-PolicyDefinition $auditDefinition
Implementación de la máquina virtual

Ha asignado roles y directivas, por lo que está listo para implementar la solución. El tamaño predeterminado es
Standard_DS1_v2, que es una de las SKU permitidas. Cuando se realiza este paso, se le solicitan las credenciales.
Los valores que especifique se configuran como el nombre de usuario y la contraseña de la máquina virtual.
New-AzVm -ResourceGroupName "myResourceGroup" `

-Name "myVM" `
-OpenPorts 80,3389
Una vez finalizada la implementación, puede aplicar más opciones de configuración de administración a la
solución.
Bloqueo de recursos
Los bloqueos de recursos impiden que los usuarios de una organización eliminen o modifiquen de forma
accidental recursos críticos. A diferencia del control de acceso basado en rol, los bloqueos de recursos aplican una
restricción a todos los usuarios y roles. Puede establecer el bloqueo de nivel en CanNotDelete o ReadOnly.
Para bloquear la máquina virtual y el grupo de seguridad de red, use el comando New -AzResourceLock:
# Add CanNotDelete lock to the VM
New-AzResourceLock -LockLevel CanNotDelete `
-LockName LockVM `
-ResourceName myVM `
-ResourceType Microsoft.Compute/virtualMachines `
# Add CanNotDelete lock to the network security group

New-AzResourceLock -LockLevel CanNotDelete `
-LockName LockNSG `
-ResourceName myNetworkSecurityGroup `
-ResourceType Microsoft.Network/networkSecurityGroups `
Para probar los bloqueos, intente ejecutar el siguiente comando:
Verá un error en el que se indica que la operación de eliminación no se puede realizar debido a un bloqueo. Solo
se puede eliminar el grupo de recursos si quita los bloqueos específicamente. Ese paso se muestra en Limpieza de
recursos.
Etiquetado de recursos
Se aplican etiquetas a los recursos de Azure para organizarlos de forma lógica por categorías. Cada etiqueta consta
de un nombre y un valor. Por ejemplo, puede aplicar el nombre "Environment" y el valor "Production" a todos los
recursos en producción.
Para agregar dos etiquetas a un grupo de recursos, use el comando Set-AzResourceGroup:
Set-AzResourceGroup -Name myResourceGroup -Tag @{ Dept="IT"; Environment="Test" }
Supongamos que desea agregar una tercera etiqueta. Cada vez que aplique etiquetas a un recurso o grupo de
recursos, sobrescribirá las etiquetas existentes en ese recurso o grupo de recursos. Para agregar una nueva
etiqueta sin perder las etiquetas existentes, debe recuperar estas, agregar una nueva etiqueta y volver a aplicar la
colección de etiquetas:
# Get existing tags and add a new tag

$tags = (Get-AzResourceGroup -Name myResourceGroup).Tags
$tags.Add("Project", "Documentation")
# Reapply the updated set of tags

Set-AzResourceGroup -Tag $tags -Name myResourceGroup
Los recursos no heredan las etiquetas del grupo de recursos. Actualmente, el grupo de recursos tiene tres etiquetas
pero los recursos no tienen ninguna. Para aplicar todas las etiquetas de un grupo de recursos a sus recursos y
conservar las etiquetas existentes en los recursos que no son duplicados, use el siguiente script:
$group = Get-AzResourceGroup myResourceGroup
if ($group.Tags -ne $null) {

# Get the resources in the resource group
$resources = Get-AzResource -ResourceGroupName $group.ResourceGroupName
# Loop through each resource

foreach ($r in $resources)
{
# Get the tags for this resource
$resourcetags = (Get-AzResource -ResourceId $r.ResourceId).Tags
# If the resource has existing tags, add new ones

if ($resourcetags)
{
foreach ($key in $group.Tags.Keys)
{
if (-not($resourcetags.ContainsKey($key)))
{
$resourcetags.Add($key, $group.Tags[$key])
}
}
# Reapply the updated tags to the resource

Set-AzResource -Tag $resourcetags -ResourceId $r.ResourceId -Force
}
else
{
Set-AzResource -Tag $group.Tags -ResourceId $r.ResourceId -Force
}
}
}
Como alternativa, puede aplicar las etiquetas desde el grupo de recursos a los recursos sin necesidad de mantener
las etiquetas existentes:

$g = Get-AzResourceGroup -Name myResourceGroup
# Find all the resources in the resource group, and for each resource apply the tags from the resource group
Get-AzResource -ResourceGroupName $g.ResourceGroupName | ForEach-Object {Set-AzResource -ResourceId
$_.ResourceId -Tag $g.Tags -Force }
Para combinar varios valores en una única etiqueta, utilice una cadena JSON.
Set-AzResourceGroup -Name myResourceGroup -Tag @{ CostCenter="{`"Dept`":`"IT`",`"Environment`":`"Test`"}" }
Para agregar una nueva etiqueta con varios valores sin perder las etiquetas existentes, debe recuperar estas, usar
una cadena JSON para la nueva etiqueta y volver a aplicar la colección de etiquetas:
# Get existing tags and add a new tag

$ResourceGroup = Get-AzResourceGroup -Name myResourceGroup
$Tags = $ResourceGroup.Tags
$Tags.Add("CostCenter", "{`"Dept`":`"IT`",`"Environment`":`"Test`"}")
# Reapply the updated set of tags

$ResourceGroup | Set-AzResourceGroup -Tag $Tags
Para quitar todas las etiquetas, pase una tabla hash vacía.
Set-AzResourceGroup -Name myResourceGroup -Tag @{ }
Para aplicar etiquetas a una máquina virtual, use el comando Set-AzResource:
# Get the virtual machine

$r = Get-AzResource -ResourceName myVM `
-ResourceType Microsoft.Compute/virtualMachines
# Apply tags to the virtual machine

Set-AzResource -Tag @{ Dept="IT"; Environment="Test"; Project="Documentation" } -ResourceId $r.ResourceId -
Force
Búsqueda de recursos por etiqueta

Para buscar recursos con un valor y nombre de etiqueta, use el comando Get-AzResource:
(Get-AzResource -Tag @{ Environment="Test"}).Name
Puede utilizar los valores devueltos para las tareas de administración, como detener todas las máquinas virtuales
con un valor de etiqueta.
Get-AzResource -Tag @{ Environment="Test"} | Where-Object {$_.ResourceType -eq

"Microsoft.Compute/virtualMachines"} | Stop-AzVM
Visualización de los costos por valores de etiqueta

Después de aplicar etiquetas a los recursos, puede ver los costos de los recursos con esas etiquetas. El análisis de
costos tarda un tiempo en mostrar el uso más reciente, por lo que quizás no pueda ver los costos todavía. Cuando
los costos están disponibles, puede ver los costos de los recursos a través de los grupos de recursos en su
suscripción. Los usuarios deben tener acceso de nivel de suscripción a la información de facturación para ver los
costos.
Para ver los costos por etiqueta en el portal, seleccione su suscripción y seleccione Análisis de costos.
A continuación, filtre por el valor de etiqueta y seleccione Aplicar.

También puede usar las API de facturación de Azure para ver los costos mediante programación.
El grupo de seguridad de red bloqueado no se puede eliminar hasta que se quite el bloqueo. Para quitar el
bloqueo, utilice el comando Remove-AzResourceLock:
Remove-AzResourceLock -LockName LockVM `

-ResourceName myVM `
-ResourceType Microsoft.Compute/virtualMachines `
Remove-AzResourceLock -LockName LockNSG `
-ResourceName myNetworkSecurityGroup `
-ResourceType Microsoft.Network/networkSecurityGroups `
Cuando ya no se necesiten, puede usar el comando Remove-AzResourceGroup para quitar el grupo de recursos, la
máquina virtual y todos los recursos relacionados.
Pasos siguientes
En este tutorial, ha creado una imagen de máquina virtual personalizada. Ha aprendido a:
Asignar un rol a los usuarios
Aplicar directivas que hagan cumplir los estándares
Proteger los recursos críticos con bloqueos
Etiquetar recursos para la facturación y la administración
Pase al siguiente tutorial para aprender a identificar los cambios y administrar las actualizaciones de paquetes en
una máquina virtual Linux.
Tutorial: Supervisión de cambios y actualización de
una máquina virtual Windows en Azure
Con Azure Change Tracking y Update Management, es fácil identificar los cambios realizados en las máquinas
virtuales Windows en Azure y administrar las actualizaciones del sistema operativo de esas mismas máquinas
virtuales.
Administrar actualizaciones de Windows.
Supervisar los cambios y el inventario.
Apertura de Azure Cloud Shell

herramientas comunes de Azure preinstaladas y configuradas para usarlas en su cuenta de Azure.
Para abrir cualquier bloque de código en Cloud Shell, seleccione Pruébelo en la esquina superior derecha del
bloque.
También puede abrir Cloud Shell en una pestaña independiente acudiendo a https://shell.azure.com/powershell.
Seleccione Copiar para copiar los bloques de código, péguelos en la pestaña Cloud Shell y seleccione la tecla
ENTRAR para ejecutar el código.
Creación de una máquina virtual

Para configurar la supervisión y la administración de actualizaciones de Azure en este tutorial, necesita una
máquina virtual Windows en Azure.
En primer lugar, establezca un nombre de usuario de administrador y una contraseña para la máquina virtual con
Get-Credential:
A continuación, cree la máquina virtual con New -AzVM. El siguiente ejemplo crea una máquina virtual llamada
myVM en la ubicación East US . Si aún no existen, se crea el grupo de recursos myResourceGroupMonitor y los
recursos de red de soporte:
New-AzVm `
-ResourceGroupName "myResourceGroupMonitor" `
-Name "myVM" `
-Credential $cred
Administrar actualizaciones de Windows

Update Management le ayuda a administrar las actualizaciones y revisiones de las máquinas virtuales Windows de
Azure. Directamente desde la máquina virtual, puede:
Evaluar el estado de las actualizaciones disponibles.
Programar la instalación de las actualizaciones necesarias.
Examinar los resultados de la implementación para comprobar que las actualizaciones se han aplicado
correctamente a la máquina virtual.
Para más información acerca de los precios, consulte Precios de automatización de la administración de
actualizaciones.
Habilitación de la Administración de actualizaciones
Para habilitar Update Management en una máquina virtual:
1. En el lado izquierdo de la ventana, seleccione Máquinas virtuales.
2. Elija una de las máquinas virtuales de la lista.
3. En el panel Operaciones de la ventana de la máquina virtual, seleccione Administración de actualizaciones.
4. Se abre la ventana Habilitar la administración de actualizaciones.
Se realiza la validación para determinar si Update Management está habilitado para esta máquina virtual. La
validación incluye comprobaciones de un área de trabajo de Log Analytics, para una cuenta de Automation
vinculada, y si la solución está en el área de trabajo.
Use un área de trabajo de Log Analytics para recopilar los datos que se generan mediante características y
servicios como Update Management. El área de trabajo proporciona una única ubicación para revisar y analizar
datos desde varios orígenes.
Para llevar a cabo en las máquinas virtuales acciones adicionales que requieran actualizaciones, puede usar Azure
Automation para ejecutar runbooks en máquinas virtuales. Estas acciones incluyen la descarga o la aplicación de
actualizaciones.
El proceso de validación también comprueba si la máquina virtual se aprovisiona con Microsoft Monitoring Agent
(MMA) y Hybrid Runbook Worker de Azure Automation. Use el agente para comunicarse con la máquina virtual y
obtener información sobre el estado de la actualización.
En la ventana Habilitar la administración de actualizaciones, elija el área de trabajo de Azure Log Analytics y
la cuenta de Automation, y seleccione Habilitar. La solución tarda un máximo de 15 minutos en habilitarse.
Los requisitos previos siguientes que falten durante la incorporación se agregarán automáticamente:
Área de trabajo de Log Analytics
Automation
Hybrid Runbook Worker, que está habilitado en la máquina virtual
Una vez habilitada la solución, se abre la ventana Administración de actualizaciones. Configure la ubicación, el
área de trabajo de Log Analytics y la cuenta de Automation que va a usar y seleccione Habilitar. Si estas opciones
aparecen atenuadas, significa que otra solución de automatización está habilitada en la máquina virtual y que
deben usarse el área de trabajo de esa solución y la cuenta de Automation.
La solución Update Management puede tardar un máximo de 15 minutos en habilitarse. Durante este tiempo, no
cierre la ventana del explorador. Después de habilitar la solución, la información sobre las actualizaciones que
faltan en la máquina virtual se pasa a los registros de Azure Monitor. Los datos pueden tardar entre 30 minutos
y 6 horas en estar disponibles para el análisis.
Visualización de la evaluación de la actualización
Una vez que Update Management esté habilitado, se abrirá la ventana Administración de actualizaciones. Una
vez que acabe la evaluación de las actualizaciones, verá una lista de las que falten en la pestaña Actualizaciones
que faltan.
Programación de una implementación de actualizaciones

Para instalar actualizaciones, programe una implementación que se ajuste a su ventana de programación y servicio
de versiones. Puede elegir los tipos de actualizaciones que desea incluir en la implementación. Por ejemplo, puede
incluir actualizaciones de seguridad o críticas y excluir paquetes acumulativos de actualizaciones.
Para programar una nueva implementación de actualizaciones en la máquina virtual, seleccione Programar
implementación de actualizaciones en la parte superior de la pantalla Administración de actualizaciones.
En la ventana Nueva implementación de actualización, especifique la siguiente información:
OPCIÓN DESCRIPCIÓN
Nombre proporcione un nombre único para identificar la

implementación de actualizaciones.
Sistema operativo Seleccione Linux o Windows.
Grupos que se deben actualizar En el caso de las máquinas virtuales hospedadas en Azure,
defina una consulta basada en una combinación de
suscripción, grupos de recursos, ubicaciones y etiquetas. Esta
consulta crea un grupo dinámico de máquinas virtuales
hospedadas en Azure que se van a incluir en la
implementación.
En el caso de las máquinas virtuales no hospedadas en Azure,
seleccione una búsqueda guardada existente. Con esta
búsqueda, puede seleccionar un grupo de estas máquinas
virtuales para incluirlas en la implementación.
Para más información, consulte Grupos dinámicos.
Máquinas para actualizar Seleccione Búsqueda guardada, Grupo importado o

Máquinas.
Si selecciona Máquinas, puede elegir máquinas individuales en

la lista desplegable. La preparación de la máquina se muestra
en la columna PREPARACIÓN DE ACTUALIZACIONES DEL
AGENTE de la tabla.
Para información sobre los distintos métodos de creación de

grupos de equipos en los registros de Azure Monitor, consulte
el artículo sobre los Grupos de equipos en los registros de
Azure Monitor
Clasificaciones de actualizaciones Elija todas las clasificaciones de actualizaciones necesarias.
Incluir o excluir las actualizaciones Seleccione esta opción para abrir el panel Incluir o excluir.
Las actualizaciones que se van a incluir y las que se van a
excluir están en pestañas separadas. Para más información
sobre cómo se controla la inclusión, consulte Programación de
una implementación de actualizaciones.
Configuración de la programación Elija la hora de inicio y seleccione Una vez o Periódico.
Scripts previos + scripts posteriores Elija los scripts que se van a ejecutar antes y después de la
implementación.
Ventana de mantenimiento Escriba el número de minutos establecido para las

actualizaciones. Los valores válidos oscilan entre 30 y 360
minutos.
Control de reinicio Seleccione cómo se controlan los reinicios. Las opciones

disponibles son:
Reiniciar si es necesario
Reiniciar siempre
No reiniciar nunca
Solo reiniciar
Reiniciar si es necesario es la opción predeterminada. Si
selecciona Solo reiniciar, no se instalarán las actualizaciones.
Después de que haya terminado de configurar la programación, haga clic en Crear para volver al panel de estado.
En la tabla Programada se muestra la programación de implementaciones que ha creado.
También se pueden crear implementaciones de actualizaciones mediante programación. Para aprender a crear una
implementación de actualizaciones con la API REST, consulte Configuraciones de actualizaciones de software:
crear. También hay un runbook de ejemplo que se puede usar para crear una implementación de actualizaciones
semanal. Para más información acerca de este runbook, consulte Create a weekly update deployment for one or
more VMs in a resource group (Crear una implementación de actualización semanal para una o más VM en un
grupo de recursos).
Visualización de los resultados de una implementación de actualizaciones
Después de que se inicie la implementación programada, puede ver su estado en la pestaña Implementaciones
de actualizaciones de la ventana Administración de actualizaciones.
Si la implementación se está ejecutando, aparece el estado "En curso". Una vez que finaliza correctamente, el
estado cambia a "Correcto". Pero si se produce un error en cualquiera de las actualizaciones de la implementación,
el estado es "Error parcial".
Seleccione la implementación de actualizaciones completada para ver el panel de esa implementación.
El icono Resultados de actualización muestra un resumen del número total de actualizaciones y los resultados
de la implementación en la máquina virtual. En la tabla de la derecha se muestra un desglose detallado de cada
actualización y los resultados de la instalación. Cada resultado tiene uno de los siguientes valores:
No intentado: La actualización no está instalada. No había suficiente tiempo disponible según la duración de
la ventana de mantenimiento definida.
Correcto: actualización realizada correctamente.
Error: error en la actualización.
Seleccione Todos los registros para ver todas las entradas de registro que creó la implementación.
Seleccione el icono Salida para ver el flujo de trabajo del runbook responsable de administrar la implementación
de actualizaciones en la máquina virtual de destino.
Seleccione Errores para ver información detallada acerca de los errores en la implementación.
Supervisión de cambios y del inventario

Puede recopilar y ver un inventario de software, archivos, demonios de Linux, servicios de Windows y claves del
Registro de Windows en los equipos. Realizar un seguimiento de las configuraciones de sus máquinas le ayuda a
identificar problemas de funcionamiento en el entorno y comprender mejor el estado de las máquinas.
Habilitación de la administración de cambios y del inventario
Para habilitar la administración de cambios y del inventario para la máquina virtual:
1. En el lado izquierdo de la ventana, seleccione Máquinas virtuales.
2. Elija una de las máquinas virtuales de la lista.
3. En Operaciones, en la ventana de la máquina virtual, seleccione Inventario o Seguimiento de cambios .
4. Se abre la página Habilitar Change Tracking e Inventario.
Configure la ubicación, el área de trabajo de Log Analytics y la cuenta de Automation que va a usar, y seleccione
Habilitar. Si las opciones aparecen atenuadas, significa que ya hay una solución de automatización habilitada para
la máquina virtual. En ese caso, se debe emplear la cuenta de Automation y el área de trabajo ya utilizados.
Aunque las soluciones aparezcan por separado en el menú, son la misma solución. Al habilitar una, se habilitan
ambas para la máquina virtual.
Una vez habilitada la solución, el inventario puede tardar un tiempo en recopilarse en la máquina virtual hasta que
aparecen los datos.
Control de cambios
En la máquina virtual, en OPERACIONES, seleccione Change Tracking y, después, seleccione Editar
configuración. Se abre el panel Change Tracking. Seleccione el tipo de configuración a la que desea realizar un
seguimiento y, después, seleccione + Agregar para configurar las opciones.
Las opciones de configuración disponibles para Windows son:
Registro de Windows
Archivos de Windows
Para obtener información detallada sobre Change Tracking, consulte Solución de los problemas de una máquina
virtual.
Visualización del inventario
EN la máquina virtual, seleccione Inventario en OPERACIONES. En la pestaña Software, hay una tabla que
muestra el software que se ha encontrado. En la tabla aparece información de alto nivel de todos y cada uno de los
registros de software. Esta información incluye el nombre del software, su versión, el editor y la última vez que se
actualizó.
Supervisión de los registros de actividad y de los cambios

En la ventana Change Tracking de la máquina virtual, seleccione Administrar conexión de registro de
actividad para abrir el panel Registro de actividad de Azure. Seleccione Conectar para conectar Change
Tracking al registro de actividad de Azure de la máquina virtual.
Después de que se habilite Change Tracking, vaya al panel Información general de la máquina virtual y
seleccione Detener para detenerla. Cuando se le solicite, seleccione Sí para detener la máquina virtual. Después
de que se haya desasignado la máquina virtual, seleccione Iniciar para reiniciar la máquina virtual.
Si se detiene y se reinicia una máquina virtual, se registrará un evento en su registro de actividad. Vuelva al panel
Change Tracking y seleccione la pestaña Eventos en la parte inferior del panel. Después de un tiempo, los
eventos aparecerán en el gráfico y en la tabla. Puede seleccionar cada uno de los eventos para ver información
detallada del mismo.
El gráfico anterior muestra los cambios que se han producido con el tiempo. Después de agregar una conexión del
registro de actividad de Azure, el gráfico de líneas de la parte superior muestra los eventos del registro de
actividad de Azure.
Cada una de las filas de los gráficos de barras representa un tipo de cambio diferente al que se puede realizar un
seguimiento. Estos tipos son demonios de Linux, archivos, claves del Registro de Windows, software y servicios de
Windows. La pestaña Cambiar muestra los detalles de los cambios. Los cambios aparecen en el orden en que han
tenido lugar. Por tanto, el primero que aparece es el último que se ha producido.
Pasos siguientes
En este tutorial ha configurado y examinado Change Tracking y Update Management en una máquina virtual. Ha
aprendido a:
Crear un grupo de recursos y una máquina virtual.
Administrar actualizaciones de Windows.
Supervisar los cambios y el inventario.
En el siguiente tutorial se explica cómo supervisar una máquina virtual.
Tutorial: Supervisión de una máquina virtual
Windows en Azure
La supervisión de Azure usa agentes para recopilar datos de arranque y de rendimiento de máquinas virtuales de
Azure, almacenar estos datos en Azure Storage y permitir el acceso a ellos mediante el portal, el módulo de Azure
PowerShell y la CLI de Azure. La supervisión avanzada se ofrece con Azure Monitor para VM mediante la
recopilación de métricas de rendimiento, la detección de los componentes de aplicación instalados en la máquina
virtual e incluye gráficos de rendimiento y asignaciones de dependencias.
Habilitar los diagnósticos de arranque en una máquina virtual
Ver los diagnósticos de arranque
Ver las métricas del host de la máquina virtual
Habilitar Azure Monitor para VM
Visualización de las métricas de rendimiento de la máquina virtual
Crear una alerta

ejecutarlos.

Para configurar la supervisión y la administración de actualizaciones de Azure en este tutorial, necesita una
máquina virtual Windows en Azure. En primer lugar, establezca un nombre de usuario de administrador y una
contraseña para la máquina virtual con Get-Credential:
Ahora cree la máquina virtual con New -AzVM. En el ejemplo siguiente se crea una máquina virtual denominada
myVM en la ubicación EastUS. Si aún no existen, se crean el grupo de recursos myResourceGroupMonitorMonitor
y los recursos de red auxiliares.
New-AzVm `
-ResourceGroupName "myResourceGroupMonitor" `
-Name "myVM" `
-Credential $cred

Cuando las máquinas virtuales Windows arrancan, el agente de diagnóstico de arranque captura una salida de
pantalla que se puede usar para solucionar problemas. Esta funcionalidad está habilitada de forma
predeterminada. Las capturas de pantalla se almacenan en una cuenta de Azure Storage, que también se crea de
forma predeterminada.
Puede obtener los datos de diagnóstico de arranque con el comando Get-AzureRmVMBootDiagnosticsData. En el
ejemplo siguiente, el diagnóstico de arranque se descarga en la raíz de la unidad *c:*.
Get-AzVMBootDiagnosticsData -ResourceGroupName "myResourceGroupMonitor" -Name "myVM" -Windows -LocalPath "c:\"
Ver las métricas del host

Una máquina virtual Windows tiene una máquina virtual host dedicada en Azure con la que interactúa. Las
métricas del host se recopilan automáticamente y se pueden ver en Azure Portal.
1. En Azure Portal, haga clic en Grupos de recursos, seleccione myResourceGroupMonitor y, después,
seleccione myVM en la lista de recursos.
2. Haga clic en Métricas en la hoja de la máquina virtual y seleccione cualquiera de las métricas del host en
Métricas disponibles para ver el funcionamiento de la máquina virtual host.
Habilitación de la supervisión avanzada

Para habilitar la supervisión de la máquina virtual de Azure con Azure Monitor para VM:
2. En la página de la VM, en la sección Supervisión, seleccione Insights (versión preliminar) .
3. En la página Insights (versión preliminar) , seleccione Probar ahora.
4. En la página Azure Monitor Insights Onboarding (Incorporación a Insights de Azure Monitor), si tiene
un área de trabajo de Log Analytics existente en la misma suscripción, selecciónela en la lista desplegable.
La lista preselecciona el área de trabajo y la ubicación predeterminadas en las que se implementa la VM en
la suscripción.
NOTE
Para crear un área de trabajo de Log Analytics nueva para almacenar los datos de supervisión de la VM, vea Creación
de un área de trabajo de Log Analytics en Azure Portal. El área de trabajo de Log Analytics debe pertenecer a una de
las regiones admitidas.
Después de habilitar la supervisión, puede que tenga que esperar unos minutos para ver las métricas de
rendimiento de la máquina virtual.
Visualización de las métricas de rendimiento de la máquina virtual

Azure Monitor para VM incluye un conjunto de gráficos de rendimiento que tienen como destino varios
indicadores clave de rendimiento (KPI) para ayudarle a determinar el rendimiento de una máquina virtual. Para
acceder desde la máquina virtual, siga estos pasos.
2. En la página de la VM, en la sección Supervisión, seleccione Insights (versión preliminar) .
3. Seleccione la pestaña Rendimiento.
Esta página no solo incluye los gráficos de uso de rendimiento, sino también una tabla para cada disco lógico
detectado, su capacidad, la utilización y la media total de cada medida.
Creación de alertas
Puede crear alertas basadas en métricas de rendimiento concretas. Se pueden usar alertas para enviar una
notificación, por ejemplo, cuando el uso medio de la CPU supera un umbral concreto o cuando el espacio libre en
disco disponible cae por debajo de una cantidad determinada. Las alertas se muestran en Azure Portal o se pueden
enviar por correo electrónico. También puede desencadenar runbooks de Azure Automation o Azure Logic Apps
en respuesta a las alertas que se generan.
En el siguiente ejemplo se crea una alerta para el uso medio de la CPU.
2. Haga clic en Reglas de alertas en la hoja de la máquina virtual y, después, en Agregar alerta de métrica
en la parte superior de la hoja de alertas.
3. Especifique un nombre para la alerta, como myAlertRule.
4. Para desencadenar una alerta cuando el porcentaje de la CPU supera 1,0 durante cinco minutos, deje el
resto de valores predeterminados seleccionados.
5. Opcionalmente, active la casilla Enviar correo electrónico a propietarios, colaboradores y lectores para
enviar una notificación por correo electrónico. La acción predeterminada es presentar una notificación en el
portal.
6. Haga clic en el botón Aceptar.
Pasos siguientes
En este tutorial ha configurado y visto el rendimiento de la máquina virtual. Ha aprendido a:
Crear un grupo de recursos y una máquina virtual
Habilitar los diagnósticos de arranque en la máquina virtual
Visualización de las métricas del host
Habilitar Azure Monitor para VM
Visualización de las métricas de la máquina virtual
Crear una alerta
Pase al siguiente tutorial para obtener información sobre Azure Security Center.
Administración de la seguridad de máquinas virtuales
Tutorial: Uso de Azure Security Center para
supervisar las máquinas virtuales Windows
Azure Security Center puede ayudarle a conocer mejor los procedimientos de seguridad de los recursos de Azure.
Security Center ofrece una supervisión integrada de la seguridad. que puede detectar las amenazas que podrían
pasar desapercibidas. En este tutorial, aprenderá no solo a usar Azure Security Center, sino también a:
Configuración de una recolección de datos
Configurar directivas de seguridad
Ver y corregir problemas de estado de la configuración
Revisar las amenazas que se detecten
Introducción a Security Center

Security Center identifica posibles problemas de configuración de máquinas virtuales (VM ) y amenazas de
seguridad dirigidas. Aquí se incluyen las máquinas virtuales que no tienen grupos de seguridad de red, los discos
sin cifrar y ataques de RDP por fuerza bruta. Esta información se muestra en el panel de Security Center en forma
de gráficos fáciles de leer.
Para acceder a dicho panel, en Azure Portal, en el menú, seleccione Security Center. Desde ahí, puede ver el
estado de la seguridad de su entorno de Azure, buscar las recomendaciones actuales y ver el estado actual de las
alertas de amenaza. Todos los gráficos de alto nivel se pueden expandir para ver más detalles.
Security Center no se limita a la detección de datos para proporcionar recomendaciones para solucionar los
problemas que identifica. Por ejemplo, si se implementa una máquina virtual sin un grupo de seguridad de red
conectado, Security Center mostrará una recomendación con los pasos que se pueden dar para aplicarla. Obtenga
la corrección automatizada sin salir del contexto de Security Center.

Para poder ver las configuraciones de seguridad de máquinas virtuales, es preciso configurar la recolección de
datos de Security Center, Esto implica activar la recopilación de datos que instala automáticamente Microsoft
Monitoring Agent en todas las máquinas virtuales en su suscripción.
1. En el panel de Security Center, haga clic en Directiva de seguridad y, luego, seleccione su suscripción.
2. En Recopilación de datos, en Aprovisionamiento automático, seleccione Activado.
3. En Configuración del área de trabajo predeterminada, deje Use workspace(s) created by Security
center (predeterminado) (Usar áreas de trabajo creadas por Security Center).
4. En Eventos de seguridad, mantenga la opción predeterminada Común.
5. Haga clic en Guardar en la parte superior de la página.
El agente de recopilación de datos de Security Center se instala en todas las máquinas virtuales y se inicia la
recolección de datos.
Configuración de una directiva de seguridad

Las directivas de seguridad se utilizan para definir los elementos para los que Security Center recopila datos y hace
recomendaciones. Se pueden aplicar diferentes directivas de seguridad a distintos conjuntos de recursos de Azure.
Aunque de forma predeterminada los recursos de Azure se evalúan con respecto a todos los elementos de la
directiva, es posible desactivar elementos individuales de la directiva tanto para todos los recursos de Azure como
para un solo grupo de recursos. Para más información acerca de las directivas de seguridad de Security Center,
consulte Establecimiento de directivas de seguridad en Azure Security Center.
Para configurar una directiva de seguridad para una suscripción entera:
2. En la hoja Directiva de seguridad, seleccione Directiva de seguridad.
3. En la hoja Directiva de seguridad - Directiva de seguridad, active o desactive los elementos de la directiva
que desee aplicar a la suscripción.
4. Cuando haya terminado de seleccionar la configuración, seleccione Aceptar en la parte superior de la hoja.
Visualización del estado de configuración de una máquina virtual

Después de que haya activado la recolección de datos y establecido una directiva de seguridad, Security Center
empieza a proporcionar alertas y recomendaciones. Cuando se implementan las máquinas virtuales, se instala el
agente de recopilación de datos. Después, Security Center se rellena con datos de las nuevas máquinas virtuales.
Para obtener información detallada acerca del estado de configuración de las máquinas virtuales, consulte
Protección de las máquinas virtuales en Azure Security Center.
A medida que se recopilan datos, se agrega el estado de los recursos de cada máquina virtual y de los recursos de
Azure relacionados, y esta información se presenta en un gráfico fácil de leer.
Para ver el estado de los recursos, siga estos pasos:
1. En el panel de Security Center, en Prevención, seleccione Proceso.
2. En la hoja Proceso, seleccione VM y equipos. Esta vista proporciona un resumen del estado de configuración
de todas las máquinas virtuales.
Para ver todas las recomendaciones existentes para una máquina virtual, seleccione la máquina en cuestión. Las
recomendaciones y las correcciones se tratan con más detalle en la siguiente sección de este tutorial.
Corrección de los problemas de configuración

Una vez que Security Center comienza a llenarse con datos de configuración, se realizan recomendaciones en
función de la directiva de seguridad configurada. Por ejemplo, si se ha configurado una máquina virtual sin un
grupo de seguridad de red asociado, una recomendación sería crear uno.
Para ver una lista de todas las recomendaciones:
1. En el panel de Security Center, seleccione Recomendaciones.
2. Seleccione una recomendación concreta. Aparece una lista de todos los recursos a los que se aplica la
recomendación.
3. Para aplicar una recomendación, seleccione el recurso.
4. Siga las instrucciones de los pasos de corrección.
En muchos casos, Security Center proporciona pasos que se pueden dar para poner en práctica recomendación sin
salir de Security Center. En el ejemplo siguiente, Security Center detecta un grupo de seguridad de red que tiene
una regla de entrada sin restricciones. En la página de la recomendación, puede hacer clic en el botón Editar
reglas de entrada. Aparecerá la interfaz de usuario necesaria para modificar la regla.
A medida que se corrigen las recomendaciones, se marcan como resueltas.
Visualización de amenazas detectadas

Además de las recomendaciones de configuración de recursos, Security Center muestra alertas de detección de
amenazas. La característica de alertas de seguridad agrega los datos recopilados de cada máquina virtual, de los
registros de redes de Azure y de las soluciones de asociados conectados para detectar las amenazas de seguridad
de los recursos de Azure. Para obtener información más detallada acerca de las funcionalidades de detección de
amenazas de Security Center, consulte ¿Cómo detecta Security Center las amenazas?.
Para poder usar la característica de alertas de seguridad, es preciso aumentar el plan de tarifa de Security Center
de Gratis a Estándar. Al pasar a este plan de tarifa superior, podrá disfrutar de una evaluación gratuita.
Para cambiar el plan de tarifa:
2. Seleccione Plan de tarifa.
3. Seleccione Estándar y, a continuación, haga clic en Guardar en la parte superior de la hoja.
Cuando haya cambiado el plan de tarifa, el gráfico de alertas de seguridad empezará a llenarse cuando se detecten
amenazas de seguridad.
Seleccione cualquiera de las alertas para ver información acerca de ella. Por ejemplo, puede ver una descripción de
la amenaza, la hora a la que se detectó, todos los intentos de amenaza y la corrección recomendada. En el ejemplo
siguiente, se detectó un ataque de RDP por fuerza bruta con 294 intentos de RDP infructuosos. Se proporciona
una corrección recomendada.
Pasos siguientes
En este tutorial, configurará Azure Security Center y, luego, revisó las máquinas virtuales de Security Center. Ha
aprendido a:
Configurar directivas de seguridad
Ver y corregir problemas de estado de la configuración
Revisar las amenazas que se detecten
Avance hasta el siguiente tutorial para aprender a instalar una pila SQL\IIS\.NET en un par de máquinas virtuales
Windows.
Pila SQL\IIS\.NET
Tutorial: Instalación de la pila SQL, IIS y .NET en una
máquina virtual Windows con Azure PowerShell
En este tutorial, vamos a instalar una pila SQL, IIS y .NET con Azure PowerShell. Esta pila está formada por dos
máquinas virtuales que ejecutan Windows Server 2016, una con IIS y .NET y la otra con SQL Server.
Crear una VM
Instalación de IIS y el SDK de .NET Core en la máquina virtual
Creación de una máquina virtual que ejecute SQL Server
Instalación de la extensión de SQL Server

ejecutarlos.
Creación de una máquina virtual de IIS

En este ejemplo, usamos el cmdlet New -AzVM en PowerShell Cloud Shell para crear rápidamente una máquina
virtual Windows Server 2016 y, a continuación, instalar IIS y .NET Framework. Las máquinas virtuales con IIS y
SQL comparten un grupo de recursos y una red virtual, por lo que creamos variables para esos nombres.
$vmName = "IISVM"
$vNetName = "myIISSQLvNet"
$resourceGroup = "myIISSQLGroup"
New-AzVm `
-ResourceGroupName $resourceGroup `
-Name $vmName `
-VirtualNetworkName $vNetName `
-SubnetName "myIISSubnet" `
-PublicIpAddressName "myIISPublicIpAddress" `
-OpenPorts 80,3389
Instale IIS y .NET Framework utilizando la extensión de script personalizado con el cmdlet Set-AzVMExtension.
Set-AzVMExtension `
-ExtensionName IIS `
-VMName $vmName `
-SettingString '{"commandToExecute":"powershell Add-WindowsFeature Web-Server,Web-Asp-Net45,NET-Framework-
Features"}' `
-Location EastUS
Creación de otra subred

Cree una segunda subred para la máquina virtual de SQL. Obtenga la red virtual mediante [Get-
AzVirtualNetwork]{/powershell/module/az.network/get-azvirtualnetwork}.
$vNet = Get-AzVirtualNetwork `
-Name $vNetName `
-ResourceGroupName $resourceGroup
Cree una configuración para la subred con Add-AzVirtualNetworkSubnetConfig.
Add-AzVirtualNetworkSubnetConfig `
-Name mySQLSubnet `
-VirtualNetwork $vNet `
-ServiceEndpoint Microsoft.Sql
Actualice la red virtual con la nueva información de subred mediante Set-AzVirtualNetwork.
$vNet | Set-AzVirtualNetwork
Máquina virtual de Azure SQL

Utilice una imagen de Marketplace de Azure configurada previamente de un servidor SQL Server para crear la
máquina virtual de SQL. Primero creamos la máquina virtual y, a continuación, vamos a instalar la extensión de
SQL Server en la máquina virtual.
New-AzVm `
-Name "mySQLVM" `
-ImageName "MicrosoftSQLServer:SQL2016SP1-WS2016:Enterprise:latest" `
-Location eastus `
-VirtualNetworkName $vNetName `
-SubnetName "mySQLSubnet" `
-PublicIpAddressName "mySQLPublicIpAddress" `
-OpenPorts 3389,1401
Use Set-AzVMSqlServerExtension para agregar la extensión de SQL Server a la máquina virtual con SQL.
Set-AzVMSqlServerExtension `
-VMName mySQLVM `
-Name "SQLExtension" `
-Location "EastUS"
Pasos siguientes
En este tutorial, ha instalado una pila SQL\IIS\.NET con Azure PowerShell. Ha aprendido a:
Crear una VM
Instalación de IIS y el SDK de .NET Core en la máquina virtual
Creación de una máquina virtual que ejecute SQL Server
Instalación de la extensión de SQL Server
Pase al siguiente tutorial para aprender a proteger un servidor web IIS con certificados SSL.
Protección de un servidor web IIS con certificados SSL
Tutorial: Protección de un servidor web en una
máquina virtual Windows en Azure con certificados
SSL almacenados en Key Vault
Para proteger los servidores web, se puede utilizar un certificado Capa de sockets seguros (SSL ) para cifrar el
tráfico web. Estos certificados SSL pueden almacenarse en Azure Key Vault y permiten implementaciones seguras
de certificados en máquinas virtuales Windows en Azure. En este tutorial, aprenderá a:
Crear una instancia de Azure Key Vault
Generar o cargar un certificado en Key Vault
Creación de una máquina virtual e instalación del servidor web IIS
Inserción del certificado en la máquina virtual y configuración de IIS con un enlace SSL

ejecutarlos.
Azure Key Vault protege claves y secretos criptográficos, como certificados y contraseñas. Key Vault ayuda a
agilizar el proceso de administración de certificados y le permite mantener el control de las claves que acceden a
ellos. Puede crear un certificado autofirmado en Key Vault o cargar un certificado de confianza existente que ya
posea.
En lugar de usar una imagen de máquina virtual personalizada que incluya los certificados preparados, inserta los
certificados en una máquina virtual en ejecución. Este proceso garantiza que los certificados más actualizados se
instalan en un servidor web durante la implementación. Si renueva o reemplaza un certificado, no tiene también
que crear una nueva imagen de máquina virtual personalizada. Los certificados más recientes se insertan
automáticamente a medida que se crean máquinas virtuales adicionales. Durante el proceso completo, el
certificado nunca deja la plataforma de Azure ni se expone en un script, historial de la línea de comandos o una
plantilla.

Para poder crear una instancia de Key Vault y certificados, cree un grupo de recursos con New -AzResourceGroup.
En el ejemplo siguiente, se crea un grupo de recursos denominado myResourceGroupSecureWeb en la ubicación
Este de EE. UU. :
$resourceGroup = "myResourceGroupSecureWeb"
$location = "East US"
New-AzResourceGroup -ResourceGroupName $resourceGroup -Location $location
A continuación, cree una instancia de Key Vault con New -AzKeyVault. Cada instancia de Key Vault requiere un
nombre único, que debe estar todo en minúsculas. Reemplace mykeyvault en el siguiente ejemplo por su propio
nombre único de Key Vault:
$keyvaultName="mykeyvault"
New-AzKeyVault -VaultName $keyvaultName `
-ResourceGroup $resourceGroup `
-Location $location `
-EnabledForDeployment
Generación de un certificado y almacenamiento en Key Vault

Para usarlo en el entorno producción, debe importar un certificado válido firmado por un proveedor de confianza
con Import-AzKeyVaultCertificate. En este tutorial, el ejemplo siguiente muestra cómo puede generar un
certificado autofirmado con Add-AzKeyVaultCertificate que usa la directiva de certificado predeterminada de New -
AzKeyVaultCertificatePolicy.
$policy = New-AzKeyVaultCertificatePolicy `
-SubjectName "CN=www.contoso.com" `
-SecretContentType "application/x-pkcs12" `
-IssuerName Self `
-ValidityInMonths 12
Add-AzKeyVaultCertificate `
-VaultName $keyvaultName `
-Name "mycert" `
-CertificatePolicy $policy

Establezca un nombre de usuario de administrador y una contraseña para la máquina virtual con Get-Credential:
Ahora puede crear la máquina virtual con New -AzVM. En el ejemplo siguiente se crea una máquina virtual
denominada myVM en la ubicación EastUS. Si aún no existen, se crean los recursos de red compatibles. Para
permitir el tráfico de web seguro, el cmdlet también abre el puerto 443.
# Create a VM
New-AzVm `
-Name "myVM" `
-Credential $cred `
-OpenPorts 443
# Use the Custom Script Extension to install IIS

Set-AzVMExtension -ResourceGroupName $resourceGroup `
-VMName "myVM" `
-ExtensionType "CustomScriptExtension" `
-SettingString '{"commandToExecute":"powershell Add-WindowsFeature Web-Server -IncludeManagementTools"}'
La máquina virtual tarda unos minutos en crearse. El último paso usa la extensión Script personalizado de Azure
para instalar el servidor web IIS con Set-AzVmExtension.
Incorporación de un certificado a la máquina virtual desde Key Vault

Para agregar el certificado desde Key Vault a una máquina virtual, obtenga el identificador de su certificado con
Get-AzKeyVaultSecret. Agregue el certificado a la máquina virtual con Add-AzVMSecret:
$certURL=(Get-AzKeyVaultSecret -VaultName $keyvaultName -Name "mycert").id
$vm=Get-AzVM -ResourceGroupName $resourceGroup -Name "myVM"

$vaultId=(Get-AzKeyVault -ResourceGroupName $resourceGroup -VaultName $keyVaultName).ResourceId
$vm = Add-AzVMSecret -VM $vm -SourceVaultId $vaultId -CertificateStore "My" -CertificateUrl $certURL
Update-AzVM -ResourceGroupName $resourceGroup -VM $vm
Configuración de IIS para utilizar el certificado

Use de nuevo la extensión Script personalizado con Set-AzVMExtension para actualizar la configuración de IIS.
Esta actualización aplica el certificado insertado desde Key Vault a IIS y configura el enlace web:
$PublicSettings = '{
"fileUris":["https://raw.githubusercontent.com/Azure-Samples/compute-automation-
configurations/master/secure-iis.ps1"],
"commandToExecute":"powershell -ExecutionPolicy Unrestricted -File secure-iis.ps1"
}'
Set-AzVMExtension -ResourceGroupName $resourceGroup `

-VMName "myVM" `
-SettingString $publicSettings
Prueba de la aplicación web segura

Obtenga la dirección IP pública de la máquina virtual con Get-AzPublicIPAddress. En el ejemplo siguiente se
obtiene la dirección IP de myPublicIP que se ha creado anteriormente:
Get-AzPublicIPAddress -ResourceGroupName $resourceGroup -Name "myPublicIPAddress" | select "IpAddress"
Ahora puede abrir un explorador web y escribir https://<myPublicIP> en la barra de direcciones. Para aceptar la
advertencia de seguridad si usó un certificado autofirmado, seleccione Detalles y, a continuación, Acceder a la
página web:
El sitio web IIS protegido se muestra ahora como en el ejemplo siguiente:

Pasos siguientes
En este tutorial, protegió un servidor web IIS con un certificado SSL almacenado en Azure Key Vault. Ha
aprendido a:
Generar o cargar un certificado en Key Vault
Creación de una máquina virtual e instalación del servidor web IIS
Inserción del certificado en la máquina virtual y configuración de IIS con un enlace SSL
Siga este vínculo para ver ejemplos de scripts de máquina virtual creados previamente.
Ejemplos de scripts de máquina virtual Windows
Ejemplos de PowerShell de máquina virtual de
Azure
En la tabla siguiente se proporcionan vínculos a ejemplos de scripts de PowerShell que crean y administran
máquinas virtuales (VM ) Windows.
Creación rápida de una máquina virtual Crea un grupo de recursos, una máquina virtual y todos los
recursos relacionados con un mínimo de mensajes.
Creación una máquina virtual completamente configurada Crea un grupo de recursos, una máquina virtual y todos los
recursos relacionados.
Creación de máquinas virtuales de alta disponibilidad Crea varias máquinas virtuales en una configuración de alta
disponibilidad y de equilibrio de carga.
Creación de una VM y ejecución de un script de Crea una máquina virtual y usa la extensión de script
configuración personalizado de Azure para instalar IIS.
Creación de una VM y ejecución de una configuración de Crea una máquina virtual y usa la extensión de
DSC configuración de estado deseado (DSC) de Azure para
instalar IIS.
Carga de un disco duro virtual y creación de máquinas Carga un archivo de VHD local en Azure, crea una imagen
virtuales desde el VHD y, después, crea una VM a partir de esa
imagen.
Creación de una máquina virtual desde un disco Crea una máquina virtual conectando un disco
administrado administrado como disco del SO.
Creación de una VM a partir de una instantánea Crea una máquina virtual desde una instantánea creando
primero un disco administrado de la instantánea y
conectando luego el nuevo disco administrado como disco
del sistema operativo.
Administrar el almacenamiento
Creación de un disco administrado desde un VHD en la Crea un disco administrado a partir de un VHD
misma suscripción o en otra especializado como un disco del sistema operativo, o a
partir de un VHD de datos como un disco de datos en la
misma suscripción o en otra.
Crear un disco administrado a partir de una instantánea Crea un disco administrado a partir de una instantánea.
Copia de un disco administrado en la misma suscripción o Copia un disco administrado en la misma suscripción o en
en otra otra, que está en la misma región que el disco administrado
primario.
Exportación de una instantánea como VHD a una cuenta de Exporta una instantánea administrada como VHD a una
almacenamiento cuenta de almacenamiento en otra región.
Exportar el disco duro virtual de un disco administrado a Exporta el VHD subyacente de un disco administrado a una
una cuenta de almacenamiento cuenta de almacenamiento en otra región.
Creación de una instantánea a partir de un disco duro Crea una instantánea a partir de un VHD y luego usa esa
virtual instantánea para crear varios discos administrados idénticos
rápidamente.
Copia de una instantánea en la misma suscripción o en otra Copia la instantánea en la misma suscripción o en otra, que
está en la misma región que la instantánea primaria.
Protección de las máquinas virtuales
Cifrado de una VM y sus discos de datos Crea un almacén de claves de Azure, una clave de cifrado y
una entidad de servicio, y luego cifra una VM.
Supervisión de una máquina virtual con Azure Monitor Crea una máquina virtual, instala el agente de Azure Log
Analytics e inscribe la VM en un área de trabajo de Log
Analytics.
Recopilación de detalles sobre todas las máquinas virtuales Crea un csv que contiene el nombre de la máquina virtual,
de una suscripción con PowerShell el nombre del grupo de recursos, la región, la red virtual, la
subred, la dirección IP privada, el tipo de sistema operativo
y la dirección IP pública de las máquinas virtuales de la
suscripción proporcionada.
Creación de una máquina virtual con PowerShell
Este script crea una máquina virtual de Azure donde se ejecuta Windows Server 2016. Después de ejecutar el
script, puede acceder a la máquina virtual a través de RDP.
Script de ejemplo
# Variables for common values
$resourceGroup = "myResourceGroup"
$location = "westeurope"
$vmName = "myVM"
# Create user object

$cred = Get-Credential -Message "Enter a username and password for the virtual machine."
# Create a resource group

New-AzResourceGroup -Name $resourceGroup -Location $location
# Create a virtual machine

New-AzVM `
-Name $vmName `
-ImageName "Win2016Datacenter" `
-PublicIpAddressName "myPublicIp" `
-Credential $cred `
-OpenPorts 3389
Limpieza de la implementación
Ejecute el siguiente comando para quitar el grupo de recursos, la máquina virtual y todos los recursos
relacionados.
Explicación del script

Este script usa los siguientes comandos para crear la implementación. Cada elemento de la tabla incluye vínculos a
la documentación específica del comando.
GET-HELP NOTAS
New-AzResourceGroup Crea un grupo de recursos en el que se almacenan todos los

recursos.
GET-HELP NOTAS
New-AzVM Crea la máquina virtual y la conecta con la tarjeta de red, la

red virtual, la subred y el grupo de seguridad de red. Este
comando también abre el puerto 80 y establece las
credenciales administrativas.
Remove-AzResourceGroup Quita un grupo de recursos y todos los recursos incluidos en

él.
Pasos siguientes
Para obtener más información sobre el módulo de Azure PowerShell, consulte la documentación de Azure
PowerShell.
Encontrará más ejemplos de scripts de Azure PowerShell de máquina virtual en la documentación sobre máquinas
virtuales Windows de Azure.
Creación una máquina virtual completamente
configurada con PowerShell
script, puede acceder a la máquina virtual a través de RDP.
Este ejemplo requiere Azure PowerShell Az 1.0, o cualquier versión posterior. Ejecute
Get-Module -ListAvailable Az para ver qué versiones están instaladas. Si necesita instalarlo, consulte Instalación
del módulo de Azure PowerShell.
Ejecute Connect AzAccount para iniciar sesión en Azure.
Script de ejemplo
$vmName = "myVM"


# Create a subnet configuration

$subnetConfig = New-AzVirtualNetworkSubnetConfig -Name mySubnet -AddressPrefix 192.168.1.0/24
# Create a virtual network

$vnet = New-AzVirtualNetwork -ResourceGroupName $resourceGroup -Location $location `
-Name MYvNET -AddressPrefix 192.168.0.0/16 -Subnet $subnetConfig
# Create a public IP address and specify a DNS name

$pip = New-AzPublicIpAddress -ResourceGroupName $resourceGroup -Location $location `
-Name "mypublicdns$(Get-Random)" -AllocationMethod Static -IdleTimeoutInMinutes 4
# Create an inbound network security group rule for port 3389

$nsgRuleRDP = New-AzNetworkSecurityRuleConfig -Name myNetworkSecurityGroupRuleRDP -Protocol Tcp `
-Direction Inbound -Priority 1000 -SourceAddressPrefix * -SourcePortRange * -DestinationAddressPrefix * `
-DestinationPortRange 3389 -Access Allow
# Create a network security group

$nsg = New-AzNetworkSecurityGroup -ResourceGroupName $resourceGroup -Location $location `
-Name myNetworkSecurityGroup -SecurityRules $nsgRuleRDP
# Create a virtual network card and associate with public IP address and NSG
$nic = New-AzNetworkInterface -Name myNic -ResourceGroupName $resourceGroup -Location $location `
-SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $pip.Id -NetworkSecurityGroupId $nsg.Id
# Create a virtual machine configuration

$vmConfig = New-AzVMConfig -VMName $vmName -VMSize Standard_D1 | `
Set-AzVMOperatingSystem -Windows -ComputerName $vmName -Credential $cred | `
Set-AzVMSourceImage -PublisherName MicrosoftWindowsServer -Offer WindowsServer -Skus 2016-Datacenter -Version
latest | `
Add-AzVMNetworkInterface -Id $nic.Id

New-AzVM -ResourceGroupName $resourceGroup -Location $location -VM $vmConfig
relacionados.

Este script usa los siguientes comandos para crear la implementación. Cada elemento de la tabla incluye vínculos
a la documentación específica del comando.
GET-HELP NOTAS
GET-HELP NOTAS

recursos.
New-AzVirtualNetworkSubnetConfig Crea una configuración de subred. Esta configuración se utiliza

con el proceso de creación de la red virtual.
New-AzVirtualNetwork Crea una red virtual.
New-AzPublicIpAddress Crea una dirección IP pública.
New-AzNetworkSecurityRuleConfig Crea configuración de regla de grupo de seguridad de red.

Esta configuración se utiliza para crear una regla NSG cuando
se crea el NSG.
New-AzNetworkSecurityGroup Crea un grupo de seguridad de red.
Get-AzVirtualNetworkSubnetConfig Obtiene la información de subred. Esta información se usa al

crear una interfaz de red.
New-AzNetworkInterface Crea una interfaz de red.
New-AzVMConfig Crea una configuración de máquina virtual. Esta configuración

incluye diversa información, como el nombre de la máquina
virtual, sistema el operativo y las credenciales administrativas.
La configuración se utiliza durante la creación de las máquinas
virtuales.
New-AzVM Cree una máquina virtual.

él.
Pasos siguientes
PowerShell.
Encontrará más ejemplos de scripts de Azure PowerShell de máquina virtual en la documentación sobre
máquinas virtuales Windows de Azure.
Equilibrio de la carga de tráfico entre máquinas
virtuales de alta disponibilidad
Este ejemplo de script crea todo lo necesario para ejecutar varias máquinas virtuales Windows Server 2016
configuradas con valores de alta disponibilidad y equilibrio de carga. Después de ejecutar el script, tendrá tres
máquinas virtuales unidas en un conjunto de disponibilidad de Azure y accesibles mediante Azure Load Balancer.
Script de ejemplo
$rgName='MyResourceGroup'
$location='eastus'

$cred = Get-Credential -Message 'Enter a username and password for the virtual machine.'
# Create a resource group.

New-AzResourceGroup -Name $rgName -Location $location
# Create a virtual network.

$subnet = New-AzVirtualNetworkSubnetConfig -Name 'MySubnet' -AddressPrefix 192.168.1.0/24
$vnet = New-AzVirtualNetwork -ResourceGroupName $rgName -Name 'MyVnet' `

-AddressPrefix 192.168.0.0/16 -Location $location -Subnet $subnet
# Create a public IP address.

$publicIp = New-AzPublicIpAddress -ResourceGroupName $rgName -Name 'myPublicIP' `
-Location $location -AllocationMethod Dynamic
# Create a front-end IP configuration for the website.

$feip = New-AzLoadBalancerFrontendIpConfig -Name 'myFrontEndPool' -PublicIpAddress $publicIp
# Create the back-end address pool.

$bepool = New-AzLoadBalancerBackendAddressPoolConfig -Name 'myBackEndPool'
# Creates a load balancer probe on port 80.

$probe = New-AzLoadBalancerProbeConfig -Name 'myHealthProbe' -Protocol Http -Port 80 `
-RequestPath / -IntervalInSeconds 360 -ProbeCount 5
# Creates a load balancer rule for port 80.

$rule = New-AzLoadBalancerRuleConfig -Name 'myLoadBalancerRuleWeb' -Protocol Tcp `
-Probe $probe -FrontendPort 80 -BackendPort 80 `
-FrontendIpConfiguration $feip -BackendAddressPool $bePool
# Create three NAT rules for port 3389.

$natrule1 = New-AzLoadBalancerInboundNatRuleConfig -Name 'myLoadBalancerRDP1' -FrontendIpConfiguration $feip `
-Protocol tcp -FrontendPort 4221 -BackendPort 3389


# Create a load balancer.

$lb = New-AzLoadBalancer -ResourceGroupName $rgName -Name 'MyLoadBalancer' -Location $location `
-FrontendIpConfiguration $feip -BackendAddressPool $bepool `
-Probe $probe -LoadBalancingRule $rule -InboundNatRule $natrule1,$natrule2,$natrule3
# Create a network security group rule for port 3389.

$rule1 = New-AzNetworkSecurityRuleConfig -Name 'myNetworkSecurityGroupRuleRDP' -Description 'Allow RDP' `
-Access Allow -Protocol Tcp -Direction Inbound -Priority 1000 `
-SourceAddressPrefix Internet -SourcePortRange * `
-DestinationAddressPrefix * -DestinationPortRange 3389

$rule2 = New-AzNetworkSecurityRuleConfig -Name 'myNetworkSecurityGroupRuleHTTP' -Description 'Allow HTTP' `

$nsg = New-AzNetworkSecurityGroup -ResourceGroupName $RgName -Location $location `
-Name 'myNetworkSecurityGroup' -SecurityRules $rule1,$rule2
# Create three virtual network cards and associate with public IP address and NSG.
$nicVM1 = New-AzNetworkInterface -ResourceGroupName $rgName -Location $location `
-Name 'MyNic1' -LoadBalancerBackendAddressPool $bepool -NetworkSecurityGroup $nsg `
-LoadBalancerInboundNatRule $natrule1 -Subnet $vnet.Subnets[0]


# Create an availability set.

$as = New-AzAvailabilitySet -ResourceGroupName $rgName -Location $location `
-Name 'MyAvailabilitySet' -Sku Aligned -PlatformFaultDomainCount 3 -PlatformUpdateDomainCount 3
# Create three virtual machines.
# ############## VM1 ###############

$vmConfig = New-AzVMConfig -VMName 'myVM1' -VMSize Standard_DS2 -AvailabilitySetId $as.Id | `
Set-AzVMOperatingSystem -Windows -ComputerName 'myVM1' -Credential $cred | `
Set-AzVMSourceImage -PublisherName MicrosoftWindowsServer -Offer WindowsServer `
-Skus 2016-Datacenter -Version latest | Add-AzVMNetworkInterface -Id $nicVM1.Id

$vm1 = New-AzVM -ResourceGroupName $rgName -Location $location -VM $vmConfig
# ############## VM2 ###############


# ############## VM3 ###############


relacionados.

GET-HELP NOTAS

recursos.

New-AzLoadBalancerFrontendIpConfig Crea una configuración de dirección IP de Front-End para un

equilibrador de carga.
New-AzLoadBalancerBackendAddressPoolConfig Crea una configuración de grupo de direcciones de back-end

para un equilibrador de carga.
New-AzLoadBalancerProbeConfig Crea una configuración de sondeo para un equilibrador de

carga.
New-AzLoadBalancerRuleConfig Crea una configuración de regla para un equilibrador de carga.
New-AzLoadBalancerInboundNatRuleConfig Crea una configuración de regla NAT entrante para un

New-AzLoadBalancer Crea un equilibrador de carga.

se crea el NSG.

GET-HELP NOTAS
Get-AzVirtualNetworkSubnetConfig Obtiene la información de subred. Esta información se usa al

crear una interfaz de red.

virtuales.

él.
También puede crear las máquinas virtuales con su propia imagen administrada personalizada. En la configuración
de la máquina virtual, para Set-AzVMSourceImage , use los parámetros -Id y -VM en lugar de -PublisherName ,
-Offer , -Skus y -Version .
Por ejemplo, crear la configuración de la máquina virtual sería:
$vmConfig = New-AzVMConfig -VMName 'myVM3' -VMSize Standard_DS1_v2 -AvailabilitySetId $as.Id | `

Set-AzVMSourceImage -Id <Image.ID of the custom managed image> | Add-AzVMNetworkInterface -Id $nicVM3.Id
Pasos siguientes
PowerShell.
Creación de una máquina virtual IIS con PowerShell
Este script crea una máquina virtual de Azure con Windows Server 2016 y, a continuación, usa la extensión de
scripts personalizados para máquinas virtuales de Azure para instalar IIS. Una vez ejecutado el script, puedo
acceder al sitio web IIS predeterminado en la dirección IP pública de la máquina virtual.
Script de ejemplo
$vmName = "myVM"



New-AzVM `
-Name $vmName `
-Credential $cred `
-OpenPorts 80
# Install IIS
$PublicSettings = '{"commandToExecute":"powershell Add-WindowsFeature Web-Server"}'
Set-AzVMExtension -ExtensionName "IIS" -ResourceGroupName $resourceGroup -VMName $vmName `

-Publisher "Microsoft.Compute" -ExtensionType "CustomScriptExtension" -TypeHandlerVersion 1.4 `
-SettingString $PublicSettings -Location $location
relacionados.

GET-HELP NOTAS

recursos.

Set-AzVMExtension Agregue una extensión de máquina virtual a la máquina

virtual. En este ejemplo, se utiliza la extensión de scripts
personalizados para instalar IIS.

él.
Pasos siguientes
PowerShell.
Creación de una máquina virtual IIS con PowerShell
Este script crea una máquina virtual de Azure con Windows Server 2016 y, a continuación, usa la extensión de
DSC para máquinas virtuales de Azure para instalar IIS. Una vez ejecutado el script, puedo acceder al sitio web IIS
predeterminado en la dirección IP pública de la máquina virtual.
Script de ejemplo
$vmName = "myVM"



New-AzVM `
-Name $vmName `
-Credential $cred `
-OpenPorts 80
# Install IIS
$PublicSettings = '{"ModulesURL":"https://github.com/Azure/azure-quickstart-templates/raw/master/dsc-
extension-iis-server-windows-vm/ContosoWebsite.ps1.zip", "configurationFunction":
"ContosoWebsite.ps1\\ContosoWebsite", "Properties": {"MachineName": "myVM"} }'
Set-AzVMExtension -ExtensionName "DSC" -ResourceGroupName $resourceGroup -VMName $vmName `

-Publisher "Microsoft.Powershell" -ExtensionType "DSC" -TypeHandlerVersion 2.19 `
-SettingString $PublicSettings -Location $location
relacionados.

GET-HELP NOTAS

recursos.


virtual. En este ejemplo, se utiliza la extensión de DSC para
instalar IIS.

él.
Pasos siguientes
PowerShell.
Script de ejemplo para cargar un disco duro virtual
en Azure y crear una máquina virtual nueva
Este script toma un archivo .vhd local de una máquina virtual generalizada y lo carga en Azure, crea una imagen
de Managed Disks y la usa para crear una máquina virtual nueva.
Script de ejemplo
# Provide values for the variables
$resourceGroup = 'myResourceGroup'
$location = 'EastUS'
$storageaccount = 'mystorageaccount'
$storageType = 'Standard_LRS'
$containername = 'mycontainer'
$localPath = 'C:\Users\Public\Documents\Hyper-V\VHDs\generalized.vhd'
$vmName = 'myVM'
$imageName = 'myImage'
$vhdName = 'myUploadedVhd.vhd'
$diskSizeGB = '128'
$subnetName = 'mySubnet'
$vnetName = 'myVnet'
$ipName = 'myPip'
$nicName = 'myNic'
$nsgName = 'myNsg'
$ruleName = 'myRdpRule'
$computerName = 'myComputerName'
$vmSize = 'Standard_DS1_v2'
# Get the username and password to be used for the administrators account on the VM.
# This is used when connecting to the VM using RDP.
# Upload the VHD

New-AzStorageAccount -ResourceGroupName $resourceGroup -Name $storageAccount -Location $location `
-SkuName $storageType -Kind "Storage"
$urlOfUploadedImageVhd = ('https://' + $storageaccount + '.blob.core.windows.net/' + $containername + '/' +
$vhdName)
Add-AzVhd -ResourceGroupName $resourceGroup -Destination $urlOfUploadedImageVhd `
-LocalFilePath $localPath
# Note: Uploading the VHD may take awhile!
# Create a managed image from the uploaded VHD

$imageConfig = New-AzImageConfig -Location $location
$imageConfig = Set-AzImageOsDisk -Image $imageConfig -OsType Windows -OsState Generalized `
-BlobUri $urlOfUploadedImageVhd
$image = New-AzImage -ImageName $imageName -ResourceGroupName $resourceGroup -Image $imageConfig
# Create the networking resources
$singleSubnet = New-AzVirtualNetworkSubnetConfig -Name $subnetName -AddressPrefix 10.0.0.0/24
$vnet = New-AzVirtualNetwork -Name $vnetName -ResourceGroupName $resourceGroup -Location $location `
-AddressPrefix 10.0.0.0/16 -Subnet $singleSubnet
$pip = New-AzPublicIpAddress -Name $ipName -ResourceGroupName $resourceGroup -Location $location `
-AllocationMethod Dynamic
$rdpRule = New-AzNetworkSecurityRuleConfig -Name $ruleName -Description 'Allow RDP' -Access Allow `
-Protocol Tcp -Direction Inbound -Priority 110 -SourceAddressPrefix Internet -SourcePortRange * `
-Name $nsgName -SecurityRules $rdpRule
$nic = New-AzNetworkInterface -Name $nicName -ResourceGroupName $resourceGroup -Location $location `
$vnet = Get-AzVirtualNetwork -ResourceGroupName $resourceGroup -Name $vnetName
# Start building the VM configuration

$vm = New-AzVMConfig -VMName $vmName -VMSize $vmSize
# Set the VM image as source image for the new VM

$vm = Set-AzVMSourceImage -VM $vm -Id $image.Id
# Finish the VM configuration and add the NIC.

$vm = Set-AzVMOSDisk -VM $vm -DiskSizeInGB $diskSizeGB -CreateOption FromImage -Caching ReadWrite
$vm = Set-AzVMOperatingSystem -VM $vm -Windows -ComputerName $computerName -Credential $cred `
-ProvisionVMAgent -EnableAutoUpdate
$vm = Add-AzVMNetworkInterface -VM $vm -Id $nic.Id
# Create the VM
New-AzVM -VM $vm -ResourceGroupName $resourceGroup -Location $location
# Verify that the VM was created

$vmList = Get-AzVM -ResourceGroupName $resourceGroup
$vmList.Name
relacionados.
Remove-AzResourceGroup -Name $resourceGroup

GET-HELP NOTAS

recursos.
New-AzStorageAccount Crea una cuenta de almacenamiento.
Add-AzVhd Carga un disco duro virtual desde una máquina virtual local a
un blob en una cuenta de almacenamiento en la nube en
Azure.
GET-HELP NOTAS
New-AzImageConfig Crea un objeto de imagen configurable.
Set-AzImageOsDisk Establece las propiedades del disco del sistema operativo en

un objeto de imagen.
New-AzImage Crea una nueva imagen.


se crea el NSG.
Get-AzVirtualNetwork Obtiene una red virtual en un grupo de recursos.

virtuales.
Set-AzVMSourceImage Especifica una imagen para una máquina virtual.
Set-AzVMOSDisk Establece las propiedades del disco del sistema operativo en

una máquina virtual.
Set-AzVMOperatingSystem Establece las propiedades del disco del sistema operativo en

una máquina virtual.
Add-AzVMNetworkInterface Agrega una interfaz de red a una máquina virtual.

él.
Pasos siguientes
PowerShell.
Creación de una máquina virtual con un disco del
SO administrado mediante PowerShell
Este script crea una máquina virtual conectando un disco administrado como disco del SO. Use este script en los
anteriores escenarios:
Creación de una máquina virtual desde un disco del SO administrado que se copió desde un disco
administrado de otra suscripción
Creación de una máquina virtual desde un disco administrado que se creó a partir de un archivo de disco duro
virtual especializado
Creación de una máquina virtual desde un disco del SO administrado que se creó a partir de una instantánea
Script de ejemplo
#Provide the subscription Id
$subscriptionId = 'yourSubscriptionId'
#Provide the name of your resource group

$resourceGroupName ='yourResourceGroupName'
#Provide the name of the snapshot that will be used to create OS disk
$snapshotName = 'yourSnapshotName'
#Provide the name of the OS disk that will be created using the snapshot
$osDiskName = 'yourOSDiskName'
#Provide the name of an existing virtual network where virtual machine will be created
$virtualNetworkName = 'yourVNETName'
#Provide the name of the virtual machine

$virtualMachineName = 'yourVMName'
#Provide the size of the virtual machine

#e.g. Standard_DS3
#Get all the vm sizes in a region using below script:
#e.g. Get-AzVMSize -Location westus
$virtualMachineSize = 'Standard_DS3'
#Set the context to the subscription Id where Managed Disk will be created
Select-AzSubscription -SubscriptionId $SubscriptionId
$snapshot = Get-AzSnapshot -ResourceGroupName $resourceGroupName -SnapshotName $snapshotName
$diskConfig = New-AzDiskConfig -Location $snapshot.Location -SourceResourceId $snapshot.Id -CreateOption Copy
$disk = New-AzDisk -Disk $diskConfig -ResourceGroupName $resourceGroupName -DiskName $osDiskName
#Initialize virtual machine configuration

$VirtualMachine = New-AzVMConfig -VMName $virtualMachineName -VMSize $virtualMachineSize
#Use the Managed Disk Resource Id to attach it to the virtual machine. Please change the OS type to linux if
OS disk has linux OS
$VirtualMachine = Set-AzVMOSDisk -VM $VirtualMachine -ManagedDiskId $disk.Id -CreateOption Attach -Windows
#Create a public IP for the VM

$publicIp = New-AzPublicIpAddress -Name ($VirtualMachineName.ToLower()+'_ip') -ResourceGroupName
$resourceGroupName -Location $snapshot.Location -AllocationMethod Dynamic
#Get the virtual network where virtual machine will be hosted

$vnet = Get-AzVirtualNetwork -Name $virtualNetworkName -ResourceGroupName $resourceGroupName
# Create NIC in the first subnet of the virtual network

$nic = New-AzNetworkInterface -Name ($VirtualMachineName.ToLower()+'_nic') -ResourceGroupName
$resourceGroupName -Location $snapshot.Location -SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $publicIp.Id
$VirtualMachine = Add-AzVMNetworkInterface -VM $VirtualMachine -Id $nic.Id
#Create the virtual machine with Managed Disk

New-AzVM -VM $VirtualMachine -ResourceGroupName $resourceGroupName -Location $snapshot.Location
relacionados.

Este script usa los siguientes comandos para obtener las propiedades del disco administrado, conectar un disco
administrado a una nueva máquina virtual y crear una máquina virtual. Cada elemento de la tabla incluye vínculos
a la documentación específica del comando.
GET-HELP NOTAS
Get-AzDisk Obtiene el objeto de disco basado en el nombre y el grupo de

recursos de un disco. La propiedad de identificador del objeto
de disco devuelto se utiliza para conectar el disco a una nueva
máquina virtual.

virtuales.
Set-AzVMOSDisk Conecta un disco administrado mediante la propiedad de

identificador del disco como disco del SO a una nueva
máquina virtual.

él.
Para las imágenes de Marketplace, utilice Set-AzVMPlan para establecer la información del plan.
Set-AzVMPlan -VM $VirtualMachine -Publisher $Publisher -Product $Product -Name $Bame
Pasos siguientes
PowerShell.
Creación de una máquina virtual a partir de una
instantánea con PowerShell
Este script crea una máquina virtual a partir de una instantánea de un disco del SO.
Script de ejemplo

#Provide the name of the snapshot that will be used to create OS disk
#Provide the name of the OS disk that will be created using the snapshot
$osDiskName = 'yourOSDiskName'
#Provide the name of an existing virtual network where virtual machine will be created
$virtualNetworkName = 'yourVNETName'
#Provide the name of the virtual machine

$virtualMachineName = 'yourVMName'
#Provide the size of the virtual machine

#e.g. Standard_DS3
#Get all the vm sizes in a region using below script:
#e.g. Get-AzVMSize -Location westus
$virtualMachineSize = 'Standard_DS3'
$diskConfig = New-AzDiskConfig -Location $snapshot.Location -SourceResourceId $snapshot.Id -CreateOption Copy
$disk = New-AzDisk -Disk $diskConfig -ResourceGroupName $resourceGroupName -DiskName $osDiskName
#Initialize virtual machine configuration

$VirtualMachine = New-AzVMConfig -VMName $virtualMachineName -VMSize $virtualMachineSize
#Use the Managed Disk Resource Id to attach it to the virtual machine. Please change the OS type to linux if
OS disk has linux OS
$VirtualMachine = Set-AzVMOSDisk -VM $VirtualMachine -ManagedDiskId $disk.Id -CreateOption Attach -Windows
#Create a public IP for the VM

$publicIp = New-AzPublicIpAddress -Name ($VirtualMachineName.ToLower()+'_ip') -ResourceGroupName
$resourceGroupName -Location $snapshot.Location -AllocationMethod Dynamic
#Get the virtual network where virtual machine will be hosted

$vnet = Get-AzVirtualNetwork -Name $virtualNetworkName -ResourceGroupName $resourceGroupName
# Create NIC in the first subnet of the virtual network

$nic = New-AzNetworkInterface -Name ($VirtualMachineName.ToLower()+'_nic') -ResourceGroupName
$resourceGroupName -Location $snapshot.Location -SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $publicIp.Id
$VirtualMachine = Add-AzVMNetworkInterface -VM $VirtualMachine -Id $nic.Id
#Create the virtual machine with Managed Disk

New-AzVM -VM $VirtualMachine -ResourceGroupName $resourceGroupName -Location $snapshot.Location
relacionados.

Este script usa los siguientes comandos para obtener las propiedades de las instantáneas, crear un disco
administrado a partir de una instantánea y crear una máquina virtual. Cada elemento de la tabla incluye vínculos a
GET-HELP NOTAS
Get-AzSnapshot Obtiene una instantánea con el nombre de la instantánea.
New-AzDiskConfig Crea una configuración de disco. Esta configuración se utiliza

con el proceso de creación del disco.
New-AzDisk Crea un disco administrado.

virtuales.
Set-AzVMOSDisk Conecta el disco administrado como disco del SO a la

máquina virtual.
New-AzVM Crea una máquina virtual.

él.
Pasos siguientes
PowerShell.
Creación de un disco administrado desde un archivo
VHD en una cuenta de almacenamiento en la misma
o distinta suscripción con PowerShell
Este script crea un disco administrado desde un archivo VHD en una cuenta de almacenamiento en la misma o
distinta suscripción. Utilice este script para importar un archivo VHD especializado (no generalizado o preparado
con sysprep) a un disco de sistema operativo administrado para crear una máquina virtual. También puede
utilizarlo para importar datos de un archivo VHD a un disco de datos administrado.
No debe crear varios discos administrados idénticos desde un archivo VHD en un período de tiempo corto. Para
crear discos administrados desde un archivo VHD, se crear una instantánea de blob del archivo VHD y, a
continuación, se utiliza para crear discos administrados. Solo se puede crear una instantánea de blob en un
minuto, lo que provoca errores de creación de disco debido a la limitación. Para evitar esta limitación, cree una
instantánea administrada desde el archivo VHD y, a continuación, use la instantánea administrada para crear
varios discos administrados en un corto período de tiempo.
Script de ejemplo
#Provide the subscription Id where Managed Disks will be created
#Provide the name of your resource group where Managed Disks will be created.
#Provide the name of the Managed Disk

$diskName = 'yourDiskName'
#Provide the size of the disks in GB. It should be greater than the VHD file size.
$diskSize = '128'
#Provide the storage type for Managed Disk. Premium_LRS or Standard_LRS.

$storageType = 'Premium_LRS'
#Provide the Azure region (e.g. westus) where Managed Disk will be located.
#This location should be same as the storage account where VHD file is stored
#Get all the Azure location using command below:
#Get-AzLocation
$location = 'westus'
#Provide the URI of the VHD file (page blob) in a storage account. Please not that this is NOT the SAS URI of
the storage container where VHD file is stored.
#e.g. https://contosostorageaccount1.blob.core.windows.net/vhds/contosovhd123.vhd
#Note: VHD file can be deleted as soon as Managed Disk is created.
$sourceVHDURI = 'https://contosostorageaccount1.blob.core.windows.net/vhds/contosovhd123.vhd'
#Provide the resource Id of the storage account where VHD file is stored.
#e.g. /subscriptions/6472s1g8-h217-446b-b509-
314e17e1efb0/resourceGroups/MDDemo/providers/Microsoft.Storage/storageAccounts/contosostorageaccount
#This is an optional parameter if you are creating managed disk in the same subscription
$storageAccountId =
'/subscriptions/yourSubscriptionId/resourceGroups/yourResourceGroupName/providers/Microsoft.Storage/storageAcc
ounts/yourStorageAccountName'
$diskConfig = New-AzDiskConfig -AccountType $storageType -Location $location -CreateOption Import -

StorageAccountId $storageAccountId -SourceUri $sourceVHDURI
New-AzDisk -Disk $diskConfig -ResourceGroupName $resourceGroupName -DiskName $diskName

Este script utiliza los comandos siguientes para crear un disco administrado desde un archivo VHD en una
suscripción distinta. Cada comando de la tabla crea un vínculo a documentación específica del comando.
GET-HELP NOTAS
New-AzDiskConfig Crea la configuración de disco que se usa para la creación del

disco. Incluye el tipo de almacenamiento, ubicación,
identificador de recurso de la cuenta de almacenamiento
donde se almacena el archivo VHD primario, identificador URI
del archivo VHD primario.
New-AzDisk Crea un disco mediante la configuración de disco, el nombre

del disco y el nombre del grupo de recursos que se pasan
como parámetros.
Pasos siguientes
Crear una máquina virtual conectando un disco administrado como disco del SO
PowerShell.
Creación de un disco administrado a partir de una
instantánea con PowerShell
Este script crea un disco administrado a partir de una instantánea. Úselo para restaurar una máquina virtual a
partir de las instantáneas de discos de sistema operativo y datos. Cree los discos de sistema operativo y datos a
partir de las instantáneas correspondientes y, luego, cree una nueva máquina virtual conectando los discos
administrados. También puede restaurar los discos de datos de una máquina virtual existente conectando los
discos de datos creados a partir de las instantáneas.
Script de ejemplo

#Provide the name of the snapshot that will be used to create Managed Disks

$diskName = 'yourManagedDiskName'
$diskSize = '128'
#Provide the storage type for Managed Disk. PremiumLRS or StandardLRS.

#Provide the Azure region (e.g. westus) where Managed Disks will be located.
#This location should be same as the snapshot location
#Get-AzLocation
$diskConfig = New-AzDiskConfig -SkuName $storageType -Location $location -CreateOption Copy -SourceResourceId

$snapshot.Id
New-AzDisk -Disk $diskConfig -ResourceGroupName $resourceGroupName -DiskName $diskName

Este script usa los siguientes comandos para crear un disco administrado a partir de una instantánea. Cada
comando de la tabla crea un vínculo a documentación específica del comando.
GET-HELP NOTAS
Get-AzSnapshot Obtiene las propiedades de la instantánea.

disco. Incluye el identificador de recurso de la instantánea
principal y una ubicación igual a la de la instantánea principal y
el tipo de almacenamiento.

como parámetros.
Pasos siguientes
Crear una máquina virtual a partir de un disco administrado
PowerShell.
Copia de discos administrados en la misma
suscripción o en otra con PowerShell
Este script crea una copia de un disco administrado existente en la misma suscripción o en otra. El nuevo disco se
crea en la misma región que el disco administrado primario.
Si es necesario, instale el módulo Azure PowerShell con las instrucciones de la guía de Azure PowerShell y ejecute
Connect-AzAccount para crear una conexión con Azure. Además, debe haber una clave pública SSH denominada "
id_rsa.pub " en el directorio .ssh del perfil de usuario.
Script de ejemplo
#Provide the subscription Id of the subscription where managed disk exists
$sourceSubscriptionId='yourSourceSubscriptionId'
#Provide the name of your resource group where managed disk exists
$sourceResourceGroupName='mySourceResourceGroupName'
#Provide the name of the managed disk

$managedDiskName='myDiskName'
#Set the context to the subscription Id where Managed Disk exists

Select-AzSubscription -SubscriptionId $sourceSubscriptionId
#Get the source managed disk

$managedDisk= Get-AzDisk -ResourceGroupName $sourceResourceGroupName -DiskName $managedDiskName
#Provide the subscription Id of the subscription where managed disk will be copied to
#If managed disk is copied to the same subscription then you can skip this step
$targetSubscriptionId='yourTargetSubscriptionId'
#Name of the resource group where snapshot will be copied to

$targetResourceGroupName='myTargetResourceGroupName'
#Set the context to the subscription Id where managed disk will be copied to
#If snapshot is copied to the same subscription then you can skip this step
Select-AzSubscription -SubscriptionId $targetSubscriptionId
$diskConfig = New-AzDiskConfig -SourceResourceId $managedDisk.Id -Location $managedDisk.Location -CreateOption

Copy
#Create a new managed disk in the target subscription and resource group
New-AzDisk -Disk $diskConfig -DiskName $managedDiskName -ResourceGroupName $targetResourceGroupName

Este script usa los siguientes comandos para crear un nuevo disco administrado en la suscripción de destino
mediante el identificador de disco administrado de origen. Cada comando de la tabla crea un vínculo a
documentación específica del comando.
GET-HELP NOTAS

disco. Incluye el identificador de recurso del disco primario y
una ubicación igual a la del disco primario.

como parámetros.
Pasos siguientes
PowerShell.
Exportación o copia de instantáneas administradas
como VHD a una cuenta de almacenamiento en otra
región con PowerShell
Este script exporta una instantánea administrada a una cuenta de almacenamiento en otra región. En primer lugar,
genera el identificador URI de SAS de la instantánea y, luego, lo usa para copiarlo en una cuenta de
almacenamiento en una región diferente. Use este script para mantener una copia de seguridad de los discos
administrados en una región distinta para la recuperación ante desastres.
Script de ejemplo
#Provide the subscription Id of the subscription where snapshot is created
$subscriptionId = "yourSubscriptionId"
#Provide the name of your resource group where snapshot is created

$resourceGroupName ="yourResourceGroupName"
#Provide the snapshot name

$snapshotName = "yourSnapshotName"
#Provide Shared Access Signature (SAS) expiry duration in seconds e.g. 3600.
#Know more about SAS here: https://docs.microsoft.com/en-us/Az.Storage/storage-dotnet-shared-access-signature-
part-1
$sasExpiryDuration = "3600"
#Provide storage account name where you want to copy the snapshot.
$storageAccountName = "yourstorageaccountName"
#Name of the storage container where the downloaded snapshot will be stored
$storageContainerName = "yourstoragecontainername"
#Provide the key of the storage account where you want to copy snapshot.
$storageAccountKey = 'yourStorageAccountKey'
#Provide the name of the VHD file to which snapshot will be copied.
$destinationVHDFileName = "yourvhdfilename"
# Set the context to the subscription Id where Snapshot is created

#Generate the SAS for the snapshot

$sas = Grant-AzSnapshotAccess -ResourceGroupName $ResourceGroupName -SnapshotName $SnapshotName -
DurationInSecond $sasExpiryDuration -Access Read
#Create the context for the storage account which will be used to copy snapshot to the storage account
$destinationContext = New-AzStorageContext -StorageAccountName $storageAccountName -StorageAccountKey
$storageAccountKey
#Copy the snapshot to the storage account

Start-AzStorageBlobCopy -AbsoluteUri $sas.AccessSAS -DestContainer $storageContainerName -DestContext
$destinationContext -DestBlob $destinationVHDFileName

Este script usa los siguientes comandos para generar el identificador URI de SAS para una instantánea
administrada y copia la instantánea en una cuenta de almacenamiento usando el URI de SAS. Cada comando de la
tabla crea un vínculo a documentación específica del comando.
GET-HELP NOTAS
Grant-AzSnapshotAccess Genera el URI de SAS de una instantánea que se usa para

copiarla en una cuenta de almacenamiento.
New-AzureStorageContext Crea un contexto de cuenta de almacenamiento con el

nombre de cuenta y la clave. Este contexto se puede usar para
realizar operaciones de lectura y escritura en la cuenta de
almacenamiento.
Start-AzureStorageBlobCopy Copia el VHD subyacente de una instantánea en una cuenta

de almacenamiento.
Pasos siguientes
Crear un disco administrado a partir de un VHD
PowerShell.
Exportación o copia del disco duro virtual de un
disco administrado en una cuenta de
almacenamiento de una región diferente con
PowerShell
Este script exporta el disco duro virtual de un disco administrado a una cuenta de almacenamiento de otra región.
Primero genera el identificador URI de SAS del disco administrado y, luego, lo usa para copiar el disco duro virtual
subyacente en una cuenta de almacenamiento de una región diferente. Use este script para copiar los discos
administrados en otra región y realizar la expansión regional.
Script de ejemplo
#Provide the subscription Id of the subscription where managed disk is created
$subscriptionId = "yourSubscriptionId"
#Provide the name of your resource group where managed is created

$resourceGroupName ="yourResourceGroupName"
#Provide the managed disk name

$diskName = "yourDiskName"
#Know more about SAS here: https://docs.microsoft.com/en-us/Az.Storage/storage-dotnet-shared-access-signature-
part-1
$sasExpiryDuration = "3600"
#Provide storage account name where you want to copy the underlying VHD of the managed disk.
$storageAccountName = "yourstorageaccountName"
#Name of the storage container where the downloaded VHD will be stored
$storageContainerName = "yourstoragecontainername"
#Provide the key of the storage account where you want to copy the VHD of the managed disk.
$storageAccountKey = 'yourStorageAccountKey'
#Provide the name of the destination VHD file to which the VHD of the managed disk will be copied.
$destinationVHDFileName = "yourvhdfilename"
#Set the value to 1 to use AzCopy tool to download the data. This is the recommended option for faster copy.
#Download AzCopy v10 from the link here: https://docs.microsoft.com/en-us/azure/storage/common/storage-use-
azcopy-v10
#Ensure that AzCopy is downloaded in the same folder as this file
#If you set the value to 0 then Start-AzStorageBlobCopy will be used. Azure storage will asynchronously copy
the data.
$useAzCopy = 1
# Set the context to the subscription Id where managed disk is created

#Generate the SAS for the managed disk

$sas = Grant-AzDiskAccess -ResourceGroupName $ResourceGroupName -DiskName $diskName -DurationInSecond
$sasExpiryDuration -Access Read
#Create the context of the storage account where the underlying VHD of the managed disk will be copied
$destinationContext = New-AzStorageContext -StorageAccountName $storageAccountName -StorageAccountKey
$storageAccountKey
#Copy the VHD of the managed disk to the storage account

if($useAzCopy -eq 1)
{
$containerSASURI = New-AzStorageContainerSASToken -Context $destinationContext -ExpiryTime(get-
date).AddSeconds($sasExpiryDuration) -FullUri -Name $storageContainerName -Permission rw
$containername,$sastokenkey = $containerSASURI -split "\?"
$containerSASURI = "$containername/$destinationVHDFileName`?$sastokenkey"
azcopy copy $sas.AccessSAS $containerSASURI
}else{
Start-AzStorageBlobCopy -AbsoluteUri $sas.AccessSAS -DestContainer $storageContainerName -DestContext

$destinationContext -DestBlob $destinationVHDFileName
}

Este script usa los siguientes comandos para generar el URI de SAS de un disco administrado y copia el disco duro
virtual subyacente en una cuenta de almacenamiento mediante dicho URI. Cada comando de la tabla crea un
vínculo a documentación específica del comando.
GET-HELP NOTAS
Grant-AzDiskAccess Genera el URI de SAS de un disco administrado que se usa

para copiar el disco duro virtual subyacente en una cuenta de
almacenamiento.
New-AzureStorageContext Crea un contexto de cuenta de almacenamiento con el

nombre de cuenta y la clave. Este contexto se puede usar para
realizar operaciones de lectura y escritura en la cuenta de
almacenamiento.
Start-AzureStorageBlobCopy Copia el VHD subyacente de una instantánea en una cuenta

de almacenamiento.
Pasos siguientes
PowerShell.
Creación de una instantánea desde un VHD para
crear varios discos administrados idénticos en poco
tiempo con PowerShell
Este script crea una instantánea desde un archivo VHD en una cuenta de almacenamiento en una misma
suscripción o en una suscripción distinta. Use este script para importar un VHD especializado (no generalizado ni
preparado con SysPrep) a una instantánea y luego usar esta instantánea para crear varios discos administrados
idénticos en poco tiempo. Además, úsela para importar un VHD de datos a una instantánea y luego use esta
instantánea para crear varios discos administrados en poco tiempo.
Script de ejemplo
#Provide the subscription Id where snapshot will be created
#Provide the name of your resource group where snapshot will be created.
#Provide the name of the snapshot

#Provide the storage type for snapshot. PremiumLRS or StandardLRS.

$storageType = 'StandardLRS'
#Provide the Azure region (e.g. westus) where snapshot will be located.
#This location should be same as the storage account location where VHD file is stored
#Get-AzLocation
#Provide the URI of the VHD file (page blob) in a storage account. Please not that this is NOT the SAS URI of
the storage container where VHD file is stored.
#e.g. https://contosostorageaccount1.blob.core.windows.net/vhds/contosovhd123.vhd
#Note: VHD file can be deleted as soon as Managed Disk is created.
$sourceVHDURI = 'https://yourStorageAccountName.blob.core.windows.net/vhds/yourVHDName.vhd'
#Provide the resource Id of the storage account where VHD file is stored.
#e.g. /subscriptions/6582b1g7-e212-446b-b509-
314e17e1efb0/resourceGroups/MDDemo/providers/Microsoft.Storage/storageAccounts/contosostorageaccount1
#This is an optional parameter if you are creating snapshot in the same subscription
$storageAccountId =
'/subscriptions/yourSubscriptionId/resourceGroups/yourResourceGroupName/providers/Microsoft.Storage/storageAcc
ounts/yourStorageAccountName'
$snapshotConfig = New-AzSnapshotConfig -AccountType $storageType -Location $location -CreateOption Import -

StorageAccountId $storageAccountId -SourceUri $sourceVHDURI
Â
New-AzSnapshot -Snapshot $snapshotConfig -ResourceGroupName $resourceGroupName -SnapshotName $snapshotName
Â
Este script utiliza los comandos siguientes para crear un disco administrado desde un archivo VHD en una
suscripción distinta. Cada comando de la tabla crea un vínculo a documentación específica del comando.
GET-HELP NOTAS

disco. Incluye tipo de almacenamiento, ubicación, identificador
de recurso de la cuenta de almacenamiento donde se
almacena el VHD principal y el URI de VHD del VHD principal.

como parámetros.
Pasos siguientes
Creación de una máquina virtual conectando un disco administrado como disco del SO
PowerShell.
Copiar instantánea de un disco administrado en la
misma suscripción o en otra con PowerShell
Este script copia una instantánea de un disco administrado en la misma suscripción o en otra. Use este script en los
escenarios siguientes:
1. Migrar una instantánea de Premium Storage (Premium_LRS ) a Standard Storage (Standard_LRS o
Standard_ZRS ) para reducir el costo.
2. Migrar una instantánea de almacenamiento con redundancia local (Premium_LRS, Standard_LRS ) a
almacenamiento con redundancia de zona (Standard_ZRS ) para beneficiarse de la mayor confiabilidad del
almacenamiento ZRS.
3. Mover una instantánea a otra suscripción de la misma región para alargar la retención.
Script de ejemplo
#Provide the subscription Id of the subscription where snapshot exists
$sourceSubscriptionId='yourSourceSubscriptionId'
#Provide the name of your resource group where snapshot exists

$sourceResourceGroupName='yourResourceGroupName'

$snapshotName='yourSnapshotName'
#Set the context to the subscription Id where snapshot exists

Select-AzSubscription -SubscriptionId $sourceSubscriptionId
#Get the source snapshot

$snapshot= Get-AzSnapshot -ResourceGroupName $sourceResourceGroupName -Name $snapshotName
#Provide the subscription Id of the subscription where snapshot will be copied to

$targetSubscriptionId='yourTargetSubscriptionId'

$targetResourceGroupName='yourTargetResourceGroupName'
#Set the context to the subscription Id where snapshot will be copied to

Select-AzSubscription -SubscriptionId $targetSubscriptionId
#We recommend you to store your snapshots in Standard storage to reduce cost. Please use Standard_ZRS in
regions where zone redundant storage (ZRS) is available, otherwise use Standard_LRS
#Please check out the availability of ZRS here: https://docs.microsoft.com/en-us/Az.Storage/common/storage-
redundancy-zrs#support-coverage-and-regional-availability
$snapshotConfig = New-AzSnapshotConfig -SourceResourceId $snapshot.Id -Location $snapshot.Location -
CreateOption Copy -SkuName Standard_LRS
#Create a new snapshot in the target subscription and resource group

New-AzSnapshot -Snapshot $snapshotConfig -SnapshotName $snapshotName -ResourceGroupName
$targetResourceGroupName

Este script usa los siguientes comandos para crear una instantánea en la suscripción de destino mediante el
identificador de la instantánea de origen. Cada comando de la tabla crea un vínculo a documentación específica del
comando.
GET-HELP NOTAS
New-AzSnapshotConfig Crea la configuración de instantánea que se usa para la

creación de instantáneas. Incluye el identificador de recurso de
la instantánea principal y una ubicación igual a la de la
instantánea principal.
New-AzSnapshot Crea una instantánea mediante la configuración de

instantánea, el nombre de instantánea y el nombre de grupo
de recursos pasados como parámetros.
Pasos siguientes
Crear una máquina virtual a partir de una instantánea
PowerShell.
Cifrado de una máquina virtual Windows con Azure
PowerShell
Este script crea un almacén Azure Key Vault seguro, claves de cifrado, una entidad de servicio de Azure Active
Directory y una máquina virtual (VM ) Windows. La máquina virtual, a continuación, se cifra mediante la clave de
cifrado del almacén de claves y las credenciales de la entidad de servicio.
Script de ejemplo
# Edit these global variables with you unique Key Vault name, resource group name and location
#Name of the Key Vault
$keyVaultName = "myKeyVault00"
#Resource Group Name
$rgName = "myResourceGroup"
#Region
#Password to place w/in the KeyVault
$password = $([guid]::NewGuid()).Guid)
$securePassword = ConvertTo-SecureString -String $password -AsPlainText -Force
#Name for the Azure AD Application
$appName = "My App"
#Name for the VM to be encrypt
$vmName = "myEncryptedVM"
#user name for the admin account in the vm being created and then encrypted
$vmAdminName = "encryptedUser"
# Register the Key Vault provider and create a resource group

New-AzResourceGroup -Location $location -Name $rgName
# Create a Key Vault and enable it for disk encryption

New-AzKeyVault `
-ResourceGroupName $rgName `
-VaultName $keyVaultName `
-EnabledForDiskEncryption
# Create a key in your Key Vault

Add-AzKeyVaultKey `
-VaultName $keyVaultName `
-Name "myKey" `
-Destination "Software"
# Put the password in the Key Vault as a Key Vault Secret so we can use it later
# We should never put passwords in scripts.
Set-AzKeyVaultSecret -VaultName $keyVaultName -Name adminCreds -SecretValue $securePassword
Set-AzKeyVaultSecret -VaultName $keyVaultName -Name protectValue -SecretValue $securePassword
# Create Azure Active Directory app and service principal

$app = New-AzADApplication -DisplayName $appName `
-HomePage "https://myapp0.contoso.com" `
-IdentifierUris "https://contoso.com/myapp0" `
-Password (Get-AzKeyVaultSecret -VaultName $keyVaultName -Name adminCreds).SecretValue
New-AzADServicePrincipal -ApplicationId $app.ApplicationId
# Set permissions to allow your AAD service principal to read keys from Key Vault
# Set permissions to allow your AAD service principal to read keys from Key Vault
Set-AzKeyVaultAccessPolicy -VaultName $keyvaultName `
-ServicePrincipalName $app.ApplicationId `
-PermissionsToKeys decrypt,encrypt,unwrapKey,wrapKey,verify,sign,get,list,update `
-PermissionsToSecrets get,list,set,delete,backup,restore,recover,purge
# Create PSCredential object for VM

$cred = New-Object System.Management.Automation.PSCredential($vmAdminName, (Get-AzKeyVaultSecret -VaultName
$keyVaultName -Name adminCreds).SecretValue)

New-AzVM `
-Name $vmName `
-Credential $cred `
-OpenPorts 3389
# Define required information for our Key Vault and keys

$keyVault = Get-AzKeyVault -VaultName $keyVaultName -ResourceGroupName $rgName;
$diskEncryptionKeyVaultUrl = $keyVault.VaultUri;
$keyVaultResourceId = $keyVault.ResourceId;
$keyEncryptionKeyUrl = (Get-AzKeyVaultKey -VaultName $keyVaultName -Name "myKey").Key.kid;
# Encrypt our virtual machine

Set-AzVMDiskEncryptionExtension `
-VMName $vmName `
-AadClientID $app.ApplicationId `
-AadClientSecret (Get-AzKeyVaultSecret -VaultName $keyVaultName -Name adminCreds).SecretValueText `
-DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl `
-DiskEncryptionKeyVaultId $keyVaultResourceId `
-KeyEncryptionKeyUrl $keyEncryptionKeyUrl `
-KeyEncryptionKeyVaultId $keyVaultResourceId
# View encryption status

Get-AzVmDiskEncryptionStatus -ResourceGroupName $rgName -VMName $vmName
<#
#clean up
Remove-AzResourceGroup -Name $rgName
#removes all of the Azure AD Applications you created w/ the same name
Remove-AzADApplication -ObjectId $app.ObjectId -Force
#>
relacionados.

GET-HELP NOTAS

recursos.
New-AzKeyVault Crea un almacén Azure Key Vault para almacenar los datos
seguros, como las claves de cifrado.
Add-AzKeyVaultKey Crea una clave de cifrado en el almacén Key Vault.
New-AzADServicePrincipal Crea una entidad de servicio de Azure Active Directory para

autenticar y controlar el acceso a las claves de cifrado de
forma segura.
Set-AzKeyVaultAccessPolicy Establece permisos en el almacén Key Vault para conceder

acceso a la entidad de servicio a las claves de cifrado.

Get-AzKeyVault Obtiene la información necesaria del almacén de claves
Set-AzVMDiskEncryptionExtension Habilita el cifrado en una máquina virtual usando las

credenciales de la entidad de servicio y la clave de cifrado.
Get-AzVmDiskEncryptionStatus Muestra el estado del proceso de cifrado de la máquina

virtual.

él.
Pasos siguientes
PowerShell.
Creación de una máquina virtual de Azure Monitor
con PowerShell
Este script crea una máquina virtual de Azure, instala el agente de Log Analytics e inscribe el sistema en un área de
trabajo de Log Analytics. Después de ejecutar el script, la máquina virtual será visible en Azure Monitor. Además,
debe actualizar la clave del área de trabajo y el identificador del área de trabajo de Log Analytics.
Script de ejemplo
# OMS ID and OMS key
$omsId = "<Replace with your OMS ID>"
$omsKey = "<Replace with your OMS key>"

$vmName = "myVM"
# Create a user object



New-AzVM `
-Name $vmName `
-Credential $cred `
-OpenPorts 3389
# Install and configure the OMS agent

$PublicSettings = New-Object psobject | Add-Member -PassThru NoteProperty workspaceId $omsId | ConvertTo-Json
$protectedSettings = New-Object psobject | Add-Member -PassThru NoteProperty workspaceKey $omsKey | ConvertTo-
Json
Set-AzVMExtension -ExtensionName "OMS" -ResourceGroupName $resourceGroup -VMName $vmName `

-Publisher "Microsoft.EnterpriseCloud.Monitoring" -ExtensionType "MicrosoftMonitoringAgent" `
-TypeHandlerVersion 1.0 -SettingString $PublicSettings -ProtectedSettingString $protectedSettings `
-Location $location
relacionados.

GET-HELP NOTAS

recursos.


virtual.

él.
Pasos siguientes
PowerShell.
Recopilar detalles sobre todas las máquinas virtuales
de una suscripción con PowerShell
Este script crea un csv que contiene el nombre de la máquina virtual, el nombre del grupo de recursos, la región, la
red virtual, la subred, la dirección IP privada, el tipo de sistema operativo y la dirección IP pública de las máquinas
virtuales de la suscripción proporcionada.

ejecutarlos.
Script de ejemplo
#Provide the subscription Id where the VMs reside
$subscriptionId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
#Provide the name of the csv file to be exported

$reportName = "myReport.csv"
Select-AzSubscription $subscriptionId
$report = @()
$vms = Get-AzVM
$publicIps = Get-AzPublicIpAddress
$nics = Get-AzNetworkInterface | ?{ $_.VirtualMachine -NE $null}
foreach ($nic in $nics) {
$info = "" | Select VmName, ResourceGroupName, Region, VirturalNetwork, Subnet, PrivateIpAddress, OsType,
PublicIPAddress
$vm = $vms | ? -Property Id -eq $nic.VirtualMachine.id
foreach($publicIp in $publicIps) {
if($nic.IpConfigurations.id -eq $publicIp.ipconfiguration.Id) {
$info.PublicIPAddress = $publicIp.ipaddress
}
}
$info.OsType = $vm.StorageProfile.OsDisk.OsType
$info.VMName = $vm.Name
$info.ResourceGroupName = $vm.ResourceGroupName
$info.Region = $vm.Location
$info.VirturalNetwork = $nic.IpConfigurations.subnet.Id.Split("/")[-3]
$info.Subnet = $nic.IpConfigurations.subnet.Id.Split("/")[-1]
$info.PrivateIpAddress = $nic.IpConfigurations.PrivateIpAddress
$report+=$info
}
$report | ft VmName, ResourceGroupName, Region, VirturalNetwork, Subnet, PrivateIpAddress, OsType,
PublicIPAddress
$report | Export-CSV "$home/$reportName"
Este script usa los siguientes comandos para crear una exportación csv de los detalles de las máquinas virtuales de
una suscripción. Cada comando de la tabla crea un vínculo a documentación específica del comando.
GET-HELP NOTAS
Select-AzSubscription Establece el inquilino, la suscripción y el entorno de los

cmdlets que se usan en la sesión actual.
Get-AzVM Obtiene las propiedades de una máquina virtual.
Get-AzPublicIpAddress Obtiene una dirección IP pública.
Get-AzNetworkInterface Obtiene una interfaz de red.
Pasos siguientes
PowerShell.
Ejemplos de la CLI de Azure para máquinas
virtuales Windows
En la tabla siguiente se incluyen vínculos a scripts de Bash creados con la CLI de Azure que implementan
máquinas virtuales Windows.
Creación de una máquina virtual Crea una máquina virtual Windows con una configuración
mínima.
Creación una máquina virtual completamente configurada Crea un grupo de recursos, una máquina virtual y todos los
recursos relacionados.
Creación de máquinas virtuales de alta disponibilidad Crea varias máquinas virtuales de alta disponibilidad y una
configuración de equilibrio de carga.
Creación de una máquina virtual y ejecución de un script de Crea una máquina virtual y usa la extensión de script
configuración personalizado de Azure para instalar IIS.
Creación de una máquina virtual y ejecución de una Crea una máquina virtual y usa la extensión de
configuración de DSC configuración de estado deseado (DSC) de Azure para
instalar IIS.
Administrar el almacenamiento
Crear disco administrado desde un disco duro virtual Crea un disco administrado desde un disco duro virtual
especializado como un disco del sistema operativo, o desde
un disco duro virtual de datos como un disco de datos.
Crear un disco administrado a partir de una instantánea Crea un disco administrado a partir de una instantánea.
Copiar el disco administrado en la misma suscripción o en Copia el disco administrado en la misma u otra suscripción
otra pero en la misma región que el disco administrado primario.
Exportar una instantánea como un disco duro virtual a una Exporta una instantánea administrada como un disco duro
cuenta de almacenamiento virtual a una cuenta de almacenamiento en una región
diferente.
Exportar el disco duro virtual de un disco administrado a Exporta el disco duro virtual subyacente de un disco
una cuenta de almacenamiento administrado a una cuenta de almacenamiento de otra
región.
Copiar una instantánea en la misma suscripción o en otra Copia la instantánea en la misma u otra suscripción, pero en
la misma región que la instantánea primaria.
Máquinas virtuales de red

Protección del tráfico de red entre máquinas virtuales Crea dos máquinas virtuales, todos los recursos
relacionados y grupos de seguridad de red internos y
externos (NSG).
Protección de máquinas virtuales
Cifrado de una máquina virtual y discos de datos Crea una instancia de Azure Key Vault, una clave de cifrado y
una entidad de servicio, y luego cifra una máquina virtual.
Supervisión de una máquina virtual con Azure Monitor Crea una máquina virtual, instala el agente de Log Analytics
e inscribe la máquina virtual en un área de trabajo de Log
Analytics.
Creación rápida de una máquina virtual con la CLI de
Azure
script, puede acceder a la máquina virtual a través de una conexión al Escritorio remoto.
Para ejecutar este ejemplo, instale la versión más reciente de la CLI de Azure. Para empezar, ejecute az login para
crear una conexión con Azure.
Los ejemplos de la CLI de Azure están escritos para el shell bash . Para ejecutar este ejemplo en Windows
PowerShell o en el símbolo del sistema, es posible que necesite cambiar algunos elementos del script.
Script de ejemplo
#!/bin/bash
# Update for your admin password

AdminPassword=ChangeYourAdminPassword1

az group create --name myResourceGroup --location westus
# Create a virtual machine.

az vm create \
--name myVM \
--admin-password $AdminPassword \
--no-wait
relacionados.
az group delete --name myResourceGroup --yes

Este script usa los siguientes comandos para crear un grupo de recursos, una máquina virtual y todos los recursos
relacionados. Cada comando de la tabla crea un vínculo a documentación específica del comando.
GET-HELP NOTAS
az group create Crea un grupo de recursos en el que se almacenan todos los

recursos.
GET-HELP NOTAS
az vm create Crea la máquina virtual y la conecta con la tarjeta de red, la

comando también especifica la imagen de máquina virtual que
se usará, y las credenciales administrativas.
az group delete Elimina un grupo de recursos, incluidos todos los recursos

anidados.
Pasos siguientes
Para más información sobre la CLI de Azure, consulte la documentación de la CLI de Azure.
Encontrará más ejemplos de scripts de la CLI de máquina virtual en la documentación sobre máquinas virtuales
Windows de Azure.
Creación de una máquina virtual con la CLI de Azure
script, puede acceder a la máquina virtual a través de una conexión al Escritorio remoto.
Script de ejemplo
#!/bin/bash


az group create --name myResourceGroup --location westeurope

az network vnet create --resource-group myResourceGroup --name myVnet --subnet-name mySubnet

az network public-ip create --resource-group myResourceGroup --name myPublicIP
# Create a network security group.

az network nsg create --resource-group myResourceGroup --name myNetworkSecurityGroup
# Create a virtual network card and associate with public IP address and NSG.
az network nic create \
--name myNic \
--vnet-name myVnet \
--subnet mySubnet \
--network-security-group myNetworkSecurityGroup \
--public-ip-address myPublicIP

az vm create \
--name myVM \
--location westeurope \
--nics myNic \
--admin-password $AdminPassword
# Open port 3389 to allow RDP traffic to host.

relacionados.

GET-HELP NOTAS

recursos.
az network vnet create Crea una red virtual y una subred de Azure.
az network public-ip create Crea una dirección IP pública con una dirección IP estática y
un nombre DNS asociado.
az network nsg create Crea un grupo de seguridad de red (NSG), que es un límite de
seguridad entre Internet y la máquina virtual.
az network nic create Crea una tarjeta de máquina virtual y la conecta con la red
virtual, la subred y el NSG.

red virtual, la subred y el NSG. Este comando también
especifica la imagen de máquina virtual que se usará, y las

anidados.
Pasos siguientes
Windows de Azure.
Equilibrio de la carga de tráfico entre máquinas
virtuales de alta disponibilidad
Este ejemplo de script crea todo lo necesario para ejecutar varias máquinas virtuales Ubuntu configuradas con
valores de alta disponibilidad y equilibrio de carga. Después de ejecutar el script, tendrá tres máquinas virtuales
unidas en un conjunto de disponibilidad de Azure y accesibles mediante Azure Load Balancer.
Script de ejemplo
#!/bin/bash



az network vnet create --resource-group myResourceGroup --name myVnet \
--address-prefix 192.168.0.0/16 --subnet-name mySubnet --subnet-prefix 192.168.1.0/24

az network public-ip create --resource-group myResourceGroup --name myPublicIP
# Create an Azure Load Balancer.

az network lb create --resource-group myResourceGroup --name myLoadBalancer --public-ip-address myPublicIP \
--frontend-ip-name myFrontEndPool --backend-pool-name myBackEndPool
# Creates an LB probe on port 80.

az network lb probe create --resource-group myResourceGroup --lb-name myLoadBalancer \
--name myHealthProbe --protocol tcp --port 80
# Creates an LB rule for port 80.

az network lb rule create --resource-group myResourceGroup --lb-name myLoadBalancer --name
myLoadBalancerRuleWeb \
--protocol tcp --frontend-port 80 --backend-port 80 --frontend-ip-name myFrontEndPool \
--backend-pool-name myBackEndPool --probe-name myHealthProbe
# Create three NAT rules for port 3389.

for i in `seq 1 3`; do
az network lb inbound-nat-rule create \
--resource-group myResourceGroup --lb-name myLoadBalancer \
--name myLoadBalancerRuleSSH$i --protocol tcp \
--frontend-port 422$i --backend-port 3389 \
--frontend-ip-name myFrontEndPool
done

az network nsg create --resource-group myResourceGroup --name myNetworkSecurityGroup
az network nsg rule create --resource-group myResourceGroup --nsg-name myNetworkSecurityGroup --name
myNetworkSecurityGroupRuleSSH \
--protocol tcp --direction inbound --source-address-prefix '*' --source-port-range '*' \
--destination-address-prefix '*' --destination-port-range 3389 --access allow --priority 1000

az network nsg rule create --resource-group myResourceGroup --nsg-name myNetworkSecurityGroup --name
myNetworkSecurityGroupRuleHTTP \
--protocol tcp --direction inbound --priority 1001 --source-address-prefix '*' --source-port-range '*' \
--destination-address-prefix '*' --destination-port-range 80 --access allow --priority 2000
# Create three virtual network cards and associate with public IP address and NSG.
az network nic create \
--resource-group myResourceGroup --name myNic$i \
--vnet-name myVnet --subnet mySubnet \
--network-security-group myNetworkSecurityGroup --lb-name myLoadBalancer \
--lb-address-pools myBackEndPool --lb-inbound-nat-rules myLoadBalancerRuleSSH$i
done
# Create an availability set.

az vm availability-set create --resource-group myResourceGroup --name myAvailabilitySet --platform-fault-
domain-count 3 --platform-update-domain-count 3
# Create three virtual machines.

az vm create \
--name myVM$i \
--availability-set myAvailabilitySet \
--nics myNic$i \
--admin-password $AdminPassword \
--no-wait
done
relacionados.

Este script usa los siguientes comandos para crear un grupo de recursos, una máquina virtual, un conjunto de
disponibilidad, un equilibrador de carga y todos los recursos relacionados. Cada comando de la tabla crea un
vínculo a documentación específica del comando.
GET-HELP NOTAS

recursos.
GET-HELP NOTAS
az network public-ip create Crea una dirección IP pública con una dirección IP estática y
un nombre DNS asociado.
az network lb create Crea un equilibrador de carga de red de Azure (NLB).
az network lb probe create Crea un sondeo de NLB. Se utiliza una prueba de NLB para
supervisar cada máquina virtual en el conjunto de NLB. Si
alguna máquina virtual deja de estar accesible, el tráfico no se
enruta a la máquina virtual.
az network lb rule create Crea una regla de NLB. En este ejemplo, se crea una regla para
el puerto 80. Según va llegando el tráfico HTTP a NLB, se
enruta al puerto 80 de una de las máquinas virtuales del
conjunto de NLB.
az network lb inbound-nat-rule create Crea una regla de traducción de direcciones de red (NAT) de
NLB. Las reglas de NAT asignan un puerto de NLB a un puerto
en una máquina virtual. En este ejemplo, se crea una regla
NAT para el tráfico SSH para cada máquina virtual del
conjunto de NLB.
az network nsg create Crea un grupo de seguridad de red (NSG), que es un límite de
seguridad entre Internet y la máquina virtual.
az network nsg rule create Crea una regla de NSG para permitir el tráfico entrante. En
este ejemplo, el puerto 22 está abierto al tráfico SSH.
az network nic create Crea una tarjeta de máquina virtual y la conecta con la red
virtual, la subred y el NSG.
az vm availability-set create Crea un conjunto de disponibilidad. Los conjuntos de

disponibilidad garantizan la disponibilidad de las aplicaciones
al repartir las máquinas virtuales entre los recursos físicos, de
forma que si se produce un error, el conjunto no se verá
afectado en su totalidad.


anidados.
Pasos siguientes
Windows de Azure.
Creación rápida de una máquina virtual con la CLI de
Azure
Este script crea una máquina virtual de Azure con Windows Server 2016 y, luego, usa la extensión de scripts
personalizados para máquinas virtuales de Azure con el fin de instalar IIS. Una vez ejecutado el script, puedo
acceder al sitio web IIS predeterminado en la dirección IP pública de la máquina virtual.
Script de ejemplo
#!/bin/bash



az vm create \
--name myVM \
# Open port 80 to allow web traffic to host.

# Use CustomScript extension to install IIS.

az vm extension set \
--publisher Microsoft.Compute \
--version 1.8 \
--name CustomScriptExtension \
--vm-name myVM \
--settings '{"commandToExecute":"powershell.exe Install-WindowsFeature -Name Web-Server"}'
relacionados.

GET-HELP NOTAS

recursos.

comando también especifica la imagen de máquina virtual que
se usará, y las credenciales administrativas.
az vm open-port Crea una regla de grupo de seguridad de red para permitir el

tráfico entrante. En este ejemplo, el puerto 80 está abierto al
tráfico HTTP.
azure vm extension set Agrega una extensión de máquina virtual a una máquina
virtual y la ejecuta. En este ejemplo, se utiliza la extensión de
scripts personalizados para instalar IIS.

anidados.
Pasos siguientes
Windows de Azure.
Creación de una máquina virtual con IIS mediante
DSC
Este script crea una máquina virtual y, a continuación, usa la extensión de scripts personalizados DSC para
máquinas virtuales de Azure para instalar y configurar IIS.
Script de ejemplo
#!/bin/bash


# Create a VM
az vm create \
--name myVM \
# Start a CustomScript extension to use a simple bash script to update, download and install WordPress and
MySQL
--name DSC \
--publisher Microsoft.Powershell \
--version 2.19 \
--vm-name myVM \
--settings '{"ModulesURL":"https://github.com/Azure/azure-quickstart-templates/raw/master/dsc-extension-
iis-server-windows-vm/ContosoWebsite.ps1.zip", "configurationFunction": "ContosoWebsite.ps1\\ContosoWebsite",
"Properties": {"MachineName": "myVM"} }'
# open port 80 to allow web traffic to host

az vm open-port \
--port 80 \
--name myVM
relacionados.

GET-HELP NOTAS

recursos.

az vm extension set Agregue la extensión de scripts personalizados a la máquina

virtual que invoca un script para instalar IIS.
az vm open-port Crea una regla de grupo de seguridad de red para permitir el

tráfico entrante. En este ejemplo, el puerto 80 está abierto al
tráfico HTTP.

anidados.
Pasos siguientes
Windows de Azure.
Creación un disco administrado a partir de un
archivo de VHD en una cuenta de almacenamiento
en la misma suscripción con CLI
Este script crea un disco administrado a partir de un archivo de VHD en una cuenta de almacenamiento en la
misma suscripción. Use este script para importar un VHD especializado (no generalizado ni preparado con
sysprep) en el disco de sistema operativo administrado para crear una máquina virtual. O bien úselo para
importar un VHD de datos en el disco de datos administrado.
Script de ejemplo
subscriptionId=mySubscriptionId
#Provide the name of your resource group.

#Ensure that resource group is already created
resourceGroupName=myResourceGroupName

diskName=myDiskName
diskSize=128
#Provide the URI of the VHD file that will be used to create Managed Disk.
# VHD file can be deleted as soon as Managed Disk is created.
# e.g. https://contosostorageaccount1.blob.core.windows.net/vhds/contosovhd123.vhd
vhdUri=https://contosostorageaccount1.blob.core.windows.net/vhds/contosoumd78620170425131836.vhd
#Provide the storage type for the Managed Disk. Premium_LRS or Standard_LRS.
storageType=Premium_LRS
#Provide the Azure location (e.g. westus) where Managed Disk will be located.
#The location should be same as the location of the storage account where VHD file is stored.
#Get all the Azure location supported for your subscription using command below:
#az account list-locations
location=westus
az account set --subscription $subscriptionId
#Create the Managed disk from the VHD file

az disk create --resource-group $resourceGroupName --name $diskName --sku $storageType --location $location --
size-gb $diskSize --source $vhdUri

Este script usa los siguientes comandos para crear un disco administrado a partir de un VHD. Cada comando de la
GET-HELP NOTAS
az disk create Crea un disco administrado usando el identificador URI de un

VHD en una cuenta de almacenamiento en la misma
suscripción.
Pasos siguientes
Se pueden encontrar ejemplos de scripts adicionales de la CLI de máquina virtual y discos administrados en la
documentación de Azure sobre máquinas virtuales Windows.
Creación de un disco administrado a partir de una
instantánea con CLI
Este script crea un disco administrado a partir de una instantánea. Úselo para restaurar una máquina virtual a
partir de las instantáneas de discos de sistema operativo y datos. Cree los discos de sistema operativo y datos a
partir de las instantáneas correspondientes y, luego, cree una nueva máquina virtual conectando los discos
administrados. También puede restaurar los discos de datos de una máquina virtual existente conectando los
discos de datos creados a partir de las instantáneas.
Script de ejemplo
#Provide the subscription Id of the subscription where you want to create Managed Disks
subscriptionId=dd80b94e-0463-4a65-8d04-c94f403879dc

#Provide the name of the snapshot that will be used to create Managed Disks
snapshotName=mySnapshotName
#Provide the name of the new Managed Disks that will be create
diskName=myDiskName
diskSize=128
#Provide the storage type for Managed Disk. Premium_LRS or Standard_LRS.

storageType=Premium_LRS
#Get the snapshot Id

snapshotId=$(az snapshot show --name $snapshotName --resource-group $resourceGroupName --query [id] -o tsv)
#Create a new Managed Disks using the snapshot Id

#Note that managed disk will be created in the same location as the snapshot
az disk create --resource-group $resourceGroupName --name $diskName --sku $storageType --size-gb $diskSize --
source $snapshotId

Este script usa los siguientes comandos para crear un disco administrado a partir de una instantánea. Cada
comando de la tabla crea un vínculo a documentación específica del comando.
GET-HELP NOTAS
az snapshot show Obtiene todas las propiedades de una instantánea usando las
propiedades de nombre y grupo de recursos de la
instantánea. La propiedad de identificador se utiliza para crear
disco administrado.
az disk create Crea un disco administrado usando un identificador de una

instantánea administrada
Pasos siguientes
Copia de discos administrados en la misma
suscripción o en otra con CLI
Este script copia un disco administrado en la misma suscripción o en otra, pero dentro de la misma región. La
copia solo funciona si las suscripciones forman parte del mismo inquilino de AAD.
Script de ejemplo
#Provide the subscription Id of the subscription where managed disk exists
sourceSubscriptionId=dd80b94e-0463-4a65-8d04-c94f403879dc
#Provide the name of your resource group where managed disk exists
sourceResourceGroupName=mySourceResourceGroupName
#Provide the name of the managed disk

managedDiskName=myDiskName
#Set the context to the subscription Id where managed disk exists

az account set --subscription $sourceSubscriptionId
#Get the managed disk Id

managedDiskId=$(az disk show --name $managedDiskName --resource-group $sourceResourceGroupName --query [id] -o
tsv)
#If managedDiskId is blank then it means that managed disk does not exist.
echo 'source managed disk Id is: ' $managedDiskId
#Provide the subscription Id of the subscription where managed disk will be copied to
targetSubscriptionId=6492b1f7-f219-446b-b509-314e17e1efb0
#Name of the resource group where managed disk will be copied to

targetResourceGroupName=mytargetResourceGroupName
#Set the context to the subscription Id where managed disk will be copied to
az account set --subscription $targetSubscriptionId
#Copy managed disk to different subscription using managed disk Id

az disk create --resource-group $targetResourceGroupName --name $managedDiskName --source $managedDiskId

Este script usa los siguientes comandos para crear un nuevo disco administrado en la suscripción de destino
mediante el identificador de disco administrado de origen. Cada comando de la tabla crea un vínculo a
GET-HELP NOTAS
az disk show Obtiene todas las propiedades de un disco administrado

usando las propiedades de nombre y grupo de recursos del
disco administrado. La propiedad del identificador se usa para
copiar el disco administrado en otra suscripción.
az disk create Copia un disco administrado mediante la creación de un

nuevo disco administrado en otra suscripción con el
identificador y nombre el disco administrado primario.
Pasos siguientes
Exportación o copia de una instantánea administrada
como un VHD a una cuenta de almacenamiento en
una región diferente con la CLI
Este script exporta una instantánea administrada a una cuenta de almacenamiento en otra región. En primer lugar,
genera el identificador URI de SAS de la instantánea y, luego, lo usa para copiarlo en una cuenta de
almacenamiento en una región diferente. Use este script para mantener una copia de seguridad de los discos
administrados en una región distinta para la recuperación ante desastres.
Script de ejemplo
#Provide the subscription Id where snapshot is created
subscriptionId=dd80b94e-0463-4a65-8d04-c94f403879dc
#Provide the name of your resource group where snapshot is created

#Provide the snapshot name

#Know more about SAS here: https://docs.microsoft.com/en-us/azure/storage/storage-dotnet-shared-access-
signature-part-1
sasExpiryDuration=3600
#Provide storage account name where you want to copy the snapshot.
storageAccountName=mystorageaccountname
#Name of the storage container where the downloaded snapshot will be stored
storageContainerName=mystoragecontainername
#Provide the key of the storage account where you want to copy snapshot.
storageAccountKey=mystorageaccountkey
#Provide the name of the VHD file to which snapshot will be copied.
destinationVHDFileName=myvhdfilename
sas=$(az snapshot grant-access --resource-group $resourceGroupName --name $snapshotName --duration-in-seconds

$sasExpiryDuration --query [accessSas] -o tsv)
az storage blob copy start --destination-blob $destinationVHDFileName --destination-container

$storageContainerName --account-name $storageAccountName --account-key $storageAccountKey --source-uri $sas

Este script usa los siguientes comandos para generar el identificador URI de SAS para una instantánea
administrada y copia la instantánea en una cuenta de almacenamiento usando el URI de SAS. Cada comando de la
GET-HELP NOTAS
az snapshot grant-access Genera la SAS de solo lectura que se usa para copiar el archivo
de VHD subyacente a una cuenta de almacenamiento o
descargarlo localmente.
az storage blob copy start Copia un blob de forma asincrónica desde una cuenta de
almacenamiento a otra.
Pasos siguientes
Exportar o copiar un disco administrado en una
cuenta de almacenamiento mediante la CLI de Azure
Este script exporta el disco duro virtual (VHD ) subyacente de un disco administrado a una cuenta de
almacenamiento de la misma región u otra diferente. Primero se genera el URI de SAS del disco administrado y,
luego, se usa para copiar el disco duro virtual (VHD ) en una cuenta de almacenamiento. Use este script para copiar
los discos administrados y realizar la expansión regional.
Script de ejemplo
#Provide the subscription Id where managed disk is created
subscriptionId=yourSubscriptionId
#Provide the name of your resource group where managed disk is created
#Provide the managed disk name

diskName=myDiskName
#Know more about SAS here: https://docs.microsoft.com/en-us/azure/storage/storage-dotnet-shared-access-
signature-part-1
sasExpiryDuration=3600
#Provide storage account name where you want to copy the underlying VHD file of the managed disk.
storageAccountName=mystorageaccountname
#Name of the storage container where the downloaded VHD will be stored
storageContainerName=mystoragecontainername
#Provide the key of the storage account where you want to copy the VHD
storageAccountKey=mystorageaccountkey
#Provide the name of the destination VHD file to which the VHD of the managed disk will be copied.
destinationVHDFileName=myvhdfilename.vhd
sas=$(az disk grant-access --resource-group $resourceGroupName --name $diskName --duration-in-seconds

$sasExpiryDuration --query [accessSas] -o tsv)
az storage blob copy start --destination-blob $destinationVHDFileName --destination-container

$storageContainerName --account-name $storageAccountName --account-key $storageAccountKey --source-uri $sas

Este script usa los siguientes comandos para generar el URI de SAS de un disco administrado y copia el disco duro
virtual (VHD ) subyacente en una cuenta de almacenamiento mediante dicho URI. Cada comando de la tabla crea
un vínculo a documentación específica del comando.
GET-HELP NOTAS
az disk grant-access Genera la SAS de solo lectura que se usa para copiar el archivo
de VHD subyacente en una cuenta de almacenamiento o
descargarlo localmente.
az storage blob copy start Copia un blob de forma asincrónica desde una cuenta de
almacenamiento a otra.
Pasos siguientes
Copia de instantánea de un disco administrado en la
misma suscripción o en otra con CLI
Este script copia una instantánea de un disco administrado en la misma suscripción o en otra. Use este script en los
escenarios siguientes:
1. Migrar una instantánea de Premium Storage (Premium_LRS ) a Standard Storage (Standard_LRS o
Standard_ZRS ) para reducir el costo.
2. Migrar una instantánea de almacenamiento con redundancia local (Premium_LRS, Standard_LRS ) a
almacenamiento con redundancia de zona (Standard_ZRS ) para beneficiarse de la mayor confiabilidad del
almacenamiento ZRS.
3. Mover una instantánea a otra suscripción de la misma región para alargar la retención.
Script de ejemplo
#Provide the subscription Id of the subscription where snapshot exists
sourceSubscriptionId=dd80b94e-0463-4a65-8d04-c94f403879dc
#Provide the name of your resource group where snapshot exists

sourceResourceGroupName=mySourceResourceGroupName

#Set the context to the subscription Id where snapshot exists

az account set --subscription $sourceSubscriptionId
#Get the snapshot Id

snapshotId=$(az snapshot show --name $snapshotName --resource-group $sourceResourceGroupName --query [id] -o
tsv)
#If snapshotId is blank then it means that snapshot does not exist.
echo 'source snapshot Id is: ' $snapshotId
#Provide the subscription Id of the subscription where snapshot will be copied to

targetSubscriptionId=6492b1f7-f219-446b-b509-314e17e1efb0

targetResourceGroupName=mytargetResourceGroupName
#Set the context to the subscription Id where snapshot will be copied to

az account set --subscription $targetSubscriptionId
#Copy snapshot to different subscription using the snapshot Id

#We recommend you to store your snapshots in Standard storage to reduce cost. Please use Standard_ZRS in
regions where zone redundant storage (ZRS) is available, otherwise use Standard_LRS
#Please check out the availability of ZRS here: https://docs.microsoft.com/en-us/azure/storage/common/storage-
redundancy-zrs#support-coverage-and-regional-availability
az snapshot create --resource-group $targetResourceGroupName --name $snapshotName --source $snapshotId --sku
Standard_LRS

Este script usa los siguientes comandos para crear una instantánea en la suscripción de destino mediante el
identificador de la instantánea de origen. Cada comando de la tabla crea un vínculo a documentación específica del
comando.
GET-HELP NOTAS
az snapshot show Obtiene todas las propiedades de una instantánea usando las
propiedades de nombre y grupo de recursos de la
instantánea. La propiedad del identificador se usa para copiar
la instantánea en otra suscripción.
az snapshot create Copia una instantánea mediante la creación de una

instantánea en otra suscripción usando el identificador y
nombre de la instantánea primaria.
Pasos siguientes
Protección del tráfico de red entre máquinas virtuales
Este script crea dos máquinas virtuales y protege el tráfico entrante en ambas. Una máquina virtual es accesible en
Internet y tiene un grupo de seguridad de red (NSG ) configurado para permitir el tráfico en el puerto 80 y el
puerto 3389. La segunda máquina virtual no es accesible en Internet, y tiene un NSG configurado para permitir el
tráfico únicamente a la primera máquina virtual.
Script de ejemplo
#!/bin/bash


# Create a virtual network and front-end subnet.

az network vnet create --resource-group myResourceGroup --name myVnet --address-prefix 10.0.0.0/16 \
--subnet-name mySubnetFrontEnd --subnet-prefix 10.0.1.0/24
# Create a back-end subnet and associate with virtual network.

az network vnet subnet create --resource-group myResourceGroup --vnet-name myVnet \
--name mySubnetBackEnd --address-prefix 10.0.2.0/24
# Create a front-end virtual machine.

az vm create --resource-group myResourceGroup --name myVMFrontEnd --image win2016datacenter \
--admin-username azureuser --admin-password $AdminPassword --vnet-name myVnet --subnet mySubnetFrontEnd \
--nsg myNetworkSecurityGroupFrontEnd --no-wait
# Create a back-end virtual machine without a public IP address.

az vm create --resource-group myResourceGroup --name myVMBackEnd --image win2016datacenter \
--admin-username azureuser --admin-password $AdminPassword --public-ip-address "" --vnet-name myVnet \
--subnet mySubnetBackEnd --nsg myNetworkSecurityGroupBackEnd
# Create front-end NSG rule to allow traffic on port 80.

az network nsg rule create --resource-group myResourceGroup --nsg-name myNetworkSecurityGroupFrontEnd \
--name http --access allow --protocol Tcp --direction Inbound --priority 200 \
--source-address-prefix "*" --source-port-range "*" --destination-address-prefix "*" --destination-port-
range 80
# Get nsg rule name.

nsgrule=$(az network nsg rule list --resource-group myResourceGroup --nsg-name myNetworkSecurityGroupBackEnd -
-query [0].name -o tsv)
# Update back-end network security group rule to limit SSH to source prefix (priority 100).
az network nsg rule update --resource-group myResourceGroup --nsg-name myNetworkSecurityGroupBackEnd \
--name $nsgrule --protocol tcp --direction inbound --priority 100 \
--source-address-prefix 10.0.1.0/24 --source-port-range '*' --destination-address-prefix '*' \
--destination-port-range 22 --access allow
# Create backend NSG rule to block all incoming traffic (priority 200).
az network nsg rule create --resource-group myResourceGroup --nsg-name myNetworkSecurityGroupBackEnd \
--name denyAll --access Deny --protocol Tcp --direction Inbound --priority 200 \
--source-address-prefix "*" --source-port-range "*" --destination-address-prefix "*" --destination-port-
range "*"
relacionados.

GET-HELP NOTAS

recursos.
az network vnet subnet create Crea una subred.

az network nsg rule update Actualiza una regla de NSG. En este ejemplo, la regla de back-
end se actualiza para que solo pase el tráfico de la subred de
front-end.
az network nsg rule list Devuelve información acerca de una regla de grupo de
seguridad de red. En este ejemplo, el nombre de la regla se
almacena en una variable para usarlo más adelante en el
script.

anidados.
Pasos siguientes
Windows de Azure.
Cifrado de una máquina virtual Windows en Azure
Este script crea una instancia segura de Azure Key Vault, claves de cifrado, una entidad de servicio de Azure Active
Directory y una máquina virtual Windows. La máquina virtual, a continuación, se cifra mediante la clave de cifrado
del almacén de claves y las credenciales de la entidad de servicio.
Script de ejemplo
#!/bin/bash
# Provide your own unique Key Vault name

keyvault_name=<your_unique_keyvault_name>
# Register the Key Vault provider and create a resource group.

az provider register -n Microsoft.KeyVault
# Create a Key Vault for storing keys and enabled for disk encryption.
az keyvault create --name $keyvault_name --resource-group myResourceGroup --location eastus \
--enabled-for-disk-encryption True
# Create a key within the Key Vault.

az keyvault key create --vault-name $keyvault_name --name myKey --protection software
# Create an Azure Active Directory service principal for authenticating requests to Key Vault.
# Read in the service principal ID and password for use in later commands.
read sp_id sp_password <<< $(az ad sp create-for-rbac --query [appId,password] -o tsv)
# Grant permissions on the Key Vault to the AAD service principal.

az keyvault set-policy --name $keyvault_name \
--spn $sp_id \
--key-permissions wrapKey \
--secret-permissions set

az vm create \
--name myVM \
--name myVM --image win2016datacenter \
--admin-password myPassword12
# Encrypt the VM disks.

az vm encryption enable --resource-group myResourceGroup --name myVM \
--aad-client-id $sp_id \
--aad-client-secret $sp_password \
--disk-encryption-keyvault $keyvault_name \
--key-encryption-key myKey \
--volume-type all
# Output how to monitor the encryption status and next steps.

echo "The encryption process can take some time. View status with:
az vm encryption show --resource-group myResourceGroup --name myVM --query [osDisk] -o tsv
When encryption status shows \`Encrypted\`, restart the VM with:
az vm restart --resource-group myResourceGroup --name myVM"
relacionados.

Este script usa los siguientes comandos para crear un grupo de recursos, un almacén Azure Key Vault, una entidad
de servicio, una máquina virtual y todos los recursos relacionados. Cada comando de la tabla crea un vínculo a
GET-HELP NOTAS

recursos.
az keyvault create Crea un almacén Azure Key Vault para almacenar los datos
seguros, como las claves de cifrado.
az keyvault key create Crea una clave de cifrado en el almacén Key Vault.
az ad sp create-for-rbac Crea una entidad de servicio de Azure Active Directory para

autenticar y controlar el acceso a las claves de cifrado de
forma segura.
az keyvault set-policy Establece permisos en el almacén Key Vault para conceder

acceso a la entidad de servicio a las claves de cifrado.

az vm encryption enable Habilita el cifrado en una máquina virtual usando las

credenciales de la entidad de servicio y la clave de cifrado.
az vm encryption show Muestra el estado del proceso de cifrado de la máquina

virtual.

anidados.
Pasos siguientes
Windows de Azure.
Supervisión de una máquina virtual con registros de
Azure Monitor
Este script crea una máquina virtual de Azure, instala el agente de Log Analytics e inscribe el sistema en un área de
trabajo de Log Analytics. Después de ejecutar el script, la máquina virtual será visible en Azure Monitor.
Script de ejemplo
#!/bin/sh

# OMS Id and OMS key.

omsid=<Replace with your OMS Id>
omskey=<Replace with your OMS key>


az vm create \
--name myVM \
# Install and configure the OMS agent.

--vm-name myVM --name MicrosoftMonitoringAgent \
--publisher Microsoft.EnterpriseCloud.Monitoring \
--version 1.0 --protected-settings '{"workspaceKey": "'"$omskey"'"}' \
--settings '{"workspaceId": "'"$omsid"'"}'
relacionados.

GET-HELP NOTAS

recursos.

azure vm extension set Ejecuta una extensión de máquina virtual en una máquina
virtual.

anidados.
Pasos siguientes
Windows de Azure.
Información general del Administrador de recursos
de Azure
Azure Resource Manager es el servicio de implementación y administración para Azure. Proporciona una capa
de administración que le permite crear, actualizar y eliminar recursos de su suscripción de Azure. Se usan las
características de administración, como el control de acceso, la auditoría y las etiquetas, para proteger y
organizar los recursos después de la implementación.
Para información acerca de las plantillas de Azure Resource Manager, consulte Información general de la
implementación de plantillas.
Capa de administración coherente

Cuando un usuario envía una solicitud de cualquiera de las herramientas, las API o los SDK de Azure, Resource
Manager recibe la solicitud. Autentica y autoriza la solicitud. Resource Manager envía la solicitud al servicio de
Azure, que lleva a cabo la acción solicitada. Dado que todas las solicitudes se controlan mediante la misma API,
verá resultados y funcionalidades coherentes en todas las distintas herramientas.
En la imagen siguiente se muestra el rol que Azure Resource Manager desempeña en el control de solicitudes
de Azure.
Todas las funcionalidades que están disponibles en el portal también lo están con Azure PowerShell, la CLI de
Azure, las API REST y los SDK de cliente. Las funcionalidades disponibles originalmente mediante las API se
incluirán en el portal a los 180 días de su lanzamiento inicial.
Terminología
Si no conoce Azure Resource Manager, estos son algunos términos con los que puede no estar familiarizado.
recurso: elemento administrable que está disponible a través de Azure. Las máquinas virtuales, cuentas de
almacenamiento, aplicaciones web, bases de datos y redes virtuales son ejemplos de recursos.
grupo de recursos: contenedor que almacena los recursos relacionados con una solución de Azure. El
grupo de recursos incluye los recursos que se desean administrar como grupo. Decida qué recursos
pertenecen a un grupo de recursos según lo que más convenga a su organización. Consulte Grupos de
recursos.
proveedor de recursos: un servicio que proporciona recursos de Azure. Por ejemplo, un proveedor de
recursos común es Microsoft.Compute, que proporciona el recurso de máquina virtual. Microsoft.Storage es
otro proveedor de recursos común. Consulte Tipos y proveedores de recursos.
Plantilla de Resource Manager: archivo de notación de objetos JavaScript (JSON ) que define uno o más
recursos para implementar en un grupo de recursos o suscripción. La plantilla se puede usar para
implementar los recursos de manera repetida y uniforme. Consulte Información general de la
implementación de plantillas.
sintaxis declarativa: sintaxis que permite establecer lo que pretende crear sin tener que escribir la
secuencia de comandos de programación para crearla. La plantilla de Resource Manager es un ejemplo de
sintaxis declarativa. En el archivo, puede definir las propiedades de la infraestructura que se va a
implementar en Azure. Consulte Información general de la implementación de plantillas.
Ventajas de usar Administrador de recursos

Con Resource Manager puede:
Administrar la infraestructura mediante plantillas declarativas en lugar de scripts.
Implementar, administrar y supervisar todos los recursos de la solución en grupo, en lugar de
controlarlos individualmente.
Volver a implementar la solución repetidamente a lo largo del ciclo de vida del desarrollo y tener la
seguridad de que los recursos se implementan de forma coherente.
Definir las dependencias entre recursos de modo que se implementen en el orden correcto.
Aplicar control de acceso a todos los servicios del grupo de recursos al integrarse de forma nativa
Control de acceso basado en rol (RBAC ) en la plataforma de administración.
Aplicar etiquetas a los recursos para organizar de manera lógica todos los recursos de la suscripción.
Aclarar la facturación de su organización viendo los costos de un grupo de recursos que compartan la
misma etiqueta.
Descripción del ámbito

Azure proporciona cuatro niveles de ámbito: grupos de administración, suscripciones, grupos de recursos y
recursos. En la imagen siguiente se muestra un ejemplo de estos niveles:
Aplicará la configuración de administración en cualquiera de estos niveles de ámbito. El nivel que seleccione
determina el grado de amplitud con que se aplica la configuración. Los niveles inferiores heredan la
configuración de los niveles superiores. Por ejemplo, al aplicar una directiva a la suscripción, esta se aplica a
todos los grupos de recursos y recursos de la suscripción. Al aplicar una directiva al grupo de recursos, esta
también se aplica al grupo de recursos y a todos sus recursos. Sin embargo, otro grupo de recursos no tiene la
asignación de dicha directiva.
Puede implementar plantillas en grupos de administración, suscripciones o grupos de recursos.
Grupos de recursos
Hay algunos factores importantes que se deben tener en cuenta al definir el grupo de recursos:
Todos los recursos del grupo deben compartir el mismo ciclo de vida. Se implementan, actualizan y
eliminan de forma conjunta. Si un recurso, como un servidor de base de datos, debe existir en un ciclo de
implementación diferente, debe estar en otro grupo de recursos.
Cada recurso solo puede existir en un grupo de recursos.
Puede agregar o quitar un recurso de un grupo de recursos en cualquier momento.
Puede mover un recurso de un grupo de recursos a otro. Para obtener más información, consulte
Traslado de los recursos a un nuevo grupo de recursos o a una nueva suscripción.
Un grupo de recursos puede contener recursos que estén ubicados en diferentes regiones.
Un grupo de recursos puede utilizarse para definir el ámbito de control de acceso para las acciones
administrativas.
Un recurso puede interactuar con los recursos de otros grupos. Esta interacción es común cuando ambos
recursos están relacionados, pero no comparten el mismo ciclo de vida (por ejemplo, aplicaciones web
que se conectan a una base de datos).
Al crear un grupo de recursos, es preciso proporcionar una ubicación para dicho grupo de recursos. Pero puede
preguntarse: "¿Por qué necesita un grupo de recursos una ubicación? Y si los recursos pueden tener
ubicaciones distintas de las del grupo de recursos, ¿por qué es importante la ubicación de este?" Los grupos de
recursos almacenan metadatos acerca de los recursos. Al especificar la ubicación del grupo de recursos, se
especifica el lugar en que dichos metadatos se almacenan. Por motivos de compatibilidad, es posible que sea
preciso asegurarse de que los datos se almacenan en una región concreta.
Si la región del grupo de recursos no está disponible temporalmente, no puede actualizar los recursos del
grupo de recursos porque los metadatos no están disponibles. Los recursos de otras regiones seguirán
funcionando según lo previsto, pero no podrá actualizarlos. Para más información sobre la creación de
aplicaciones confiables, consulte Diseño de aplicaciones de Azure confiables.
Resistencia de Azure Resource Manager

El servicio Azure Resource Manager está diseñado para proporcionar resistencia y disponibilidad continua. Las
operaciones de Resource Manager y del plano de control (solicitudes enviadas a management.azure.com) en la
API REST:
Se distribuyen entre regiones. Algunos servicios son regionales.
Se distribuyen entre las zonas de disponibilidad (así como regiones) en aquellas ubicaciones que tienen
varias zonas de disponibilidad.
No dependen de un solo centro de datos lógicos.
Nunca se interrumpen debido a actividades de mantenimiento.
Esta resistencia se aplica a los servicios que reciben las solicitudes a través de Resource Manager. Por ejemplo,
Key Vault se beneficia de esta resistencia.
Pasos siguientes
Para todas las operaciones que ofrecen los proveedores de recursos, consulte las API REST de Azure.
Para más información sobre cómo mover recursos, consulte Traslado de los recursos a un nuevo grupo
de recursos o a una nueva suscripción.
Para información sobre el etiquetado de recursos, consulte Uso de etiquetas para organizar los recursos.
Para más información sobre el bloqueo de recursos, consulte Bloqueo de recursos para impedir cambios
inesperados.
Para información sobre la creación de plantillas para implementaciones, consulte Información general
sobre la implementación de plantillas.
Regiones para las máquinas virtuales de Azure
Es importante saber cómo y donde operan las máquinas virtuales (VM ) en Azure, así como las opciones para
maximizar el rendimiento, la disponibilidad y la redundancia. Este artículo proporciona una visión general de las
características de disponibilidad y redundancia de Azure.
¿Cuáles son las regiones de Azure?

Azure funciona en varios centros de datos del mundo. Estos centros de datos se agrupan en regiones geográficas,
proporcionándole flexibilidad al elegir dónde crear sus aplicaciones.
Los recursos de Azure se crean en regiones geográficas definidas como 'Oeste de EE. UU.', 'Europa del Norte' o
'Sudeste Asiático'. Puede revisar la lista de regiones y sus ubicaciones. En cada región existen varios centros de
datos que proporcionan redundancia y disponibilidad. Este enfoque proporciona flexibilidad al diseñar aplicaciones
para crear máquinas virtuales más cercanas a los usuarios y satisfacer cualquier propósito legal, de cumplimiento
normativo o fiscal.
Regiones de Azure especiales

Azure tiene algunas regiones especiales que se pueden usar al crear las aplicaciones, en lo referente al
cumplimiento normativo o a aspectos legales. Entre dichas regiones se incluyen:
Virginia Gob. EE. UU. e Iowa Gob. EE. UU.
Una instancia física y lógica con aislamiento de red de Azure para asociados y agencias de la
administración pública de EE. UU., operada por personal estadounidense seleccionado con rigor. Incluye
certificaciones de cumplimiento adicionales como FedRAMP y DISA. Más información sobre Azure
Government.
China (Este) y China (Norte)
Estas regiones están disponibles gracias a una exclusiva asociación entre Microsoft y 21Vianet, por el
cual Microsoft no mantiene directamente los centros de datos. Obtenga más información sobre Azure
China 21Vianet.
Centro de Alemania y Noreste de Alemania
Estas regiones están disponibles mediante un modelo de administrador de datos con el cual los datos del
cliente permanecen en Alemania bajo el control de T-Systems, una empresa perteneciente a Deutsche
Telekom que actúa como administrador de datos en Alemania.
Pares de región
Cada región de Azure se empareja con otra región de la misma zona geográfica (por ejemplo, EE. UU., Europa o
Asia). Este enfoque permite la replicación de recursos, como el almacenamiento de máquina virtual, en una zona
geográfica que debe reducir la probabilidad de desastres naturales, disturbios civiles, cortes del suministro eléctrico
o interrupciones de la red física que afectan simultáneamente a ambas regiones. Entre las ventajas adicionales de
los pares de región se incluyen:
En caso de producirse una interrupción de Azure más amplia, una región tiene prioridad por cada pareja para
ayudar a reducir el tiempo de restauración de las aplicaciones.
Las actualizaciones planeadas de Azure se implementan una a una en regiones emparejadas para minimizar el
tiempo de inactividad y el riesgo de interrupción de la aplicación.
Los datos siguen residiendo en la misma zona geográfica que su pareja (excepto Sur de Brasil) con fines de
jurisdicción fiscal y de aplicación de la ley.
Entre los ejemplos de pares de región se incluyen:
PRINCIPAL SECUNDARIO
Oeste de EE. UU. East US
Europa del Norte Europa occidental
Sudeste asiático Asia oriental
Puede consultar en su totalidad la lista de pares regionales aquí.
Disponibilidad de características
Algunos servicios o características de las máquinas virtuales solo están disponibles en determinadas regiones,
como, por ejemplo, tipos de almacenamiento o tamaños de VM específicos. También hay algunos servicios
globales de Azure que no requieren que seleccione una región concreta, como Azure Active Directory, Traffic
Manager o DNS de Azure. Para obtener ayuda con el diseño del entorno de la aplicación, puede comprobar la
disponibilidad de servicios de Azure en cada región. También puede consultar mediante programación los tamaños
de máquina virtual admitidos y las restricciones de cada región.
Disponibilidad de almacenamiento
Es importante comprender las regiones y zonas geográficas de Azure a la hora de considerar las opciones de
replicación de almacenamiento disponibles. Según el tipo de almacenamiento, tendrá opciones de replicación
diferentes.
Azure Managed Disks
Almacenamiento con redundancia local (LRS )
Replica los datos tres veces dentro de la región en la que creó su cuenta de almacenamiento.
Discos basados en cuentas de almacenamiento
Almacenamiento con redundancia local (LRS )
Replica los datos tres veces dentro de la región en la que creó su cuenta de almacenamiento.
Almacenamiento con redundancia de zona (ZRS )
Replica sus datos tres veces entre dos o tres instalaciones, ya sea dentro de una sola región o entre dos
regiones.
Almacenamiento con redundancia geográfica (GRS )
Replica sus datos en una región secundaria que se encuentra a cientos de kilómetros de distancia de la
región primaria.
Almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS ).
Replica sus datos en una región secundaria, al igual que con GRS, pero también proporciona acceso de
solo lectura a los datos en la ubicación secundaria.
La tabla siguiente proporciona una breve descripción de las diferencias entre los tipos de replicación de
almacenamiento:
ESTRATEGIA DE
REPLICACIÓN LRS ZRS GRS RA-GRS
Los datos se replican Sin Sí Sí Sí

entre varias
instalaciones
Los datos se pueden Sin No No Sí

leer tanto desde la
ubicación secundaria
como desde la
ubicación principal.
Cantidad de copias de 3 3 6 6
datos mantenidas en
nodos independientes
Puede obtener más información sobre las opciones de replicación de Azure Storage aquí. Para más información
acerca de los discos administrados, consulte Azure Managed Disks overview (Introducción a los discos
administrados de Azure).
Costos de almacenamiento
Los precios varían según el tipo de almacenamiento y la disponibilidad que seleccione.
Azure Managed Disks
Las copias de seguridad de Managed Disks premium se realizan en unidades de estado sólido (SSD ) y las de
Managed Disks estándar en discos de rotación normales. Los discos administrados premium y estándar se
cobran en función de la capacidad aprovisionada para el disco.
Discos no administrados
Premium Storage está respaldado por unidades de estado sólido (SSD ) y se cobra según la capacidad del disco.
El almacenamiento estándar está respaldado por los discos giratorios habituales y se cobra según la capacidad
en uso y la disponibilidad de almacenamiento deseada.
Para RA-GRS, existe un cargo adicional por la transferencia de datos de replicación geográfica por el
ancho de banda de replicar dichos datos en otra región de Azure.
Consulte Precios de Azure Storage para más información sobre los diferentes tipos de almacenamiento y opciones
de disponibilidad.
Opciones de disponibilidad para las máquinas
virtuales de Azure
En este artículo proporciona una visión general de las características de disponibilidad de las máquinas virtuales
(VM ) de Azure.
Alta disponibilidad
Por lo general, las cargas de trabajo se distribuyen entre máquinas virtuales distintas para obtener un alto
rendimiento y crear redundancia en caso de que una máquina virtual se vea afectada debido a una actualización u
otro evento.
Hay algunas opciones que Azure proporciona para lograr alta disponibilidad. En primer lugar, hablemos sobre las
construcciones básicas.
Zonas de disponibilidad
Las zonas de disponibilidad expanden el nivel de control que tiene para mantener la disponibilidad de las
aplicaciones y los datos en las máquinas virtuales. Una zona de disponibilidad es una zona separada físicamente
dentro de una región de Azure. Hay tres zonas de disponibilidad por cada región de Azure admitida.
Cada zona de disponibilidad tiene una fuente de alimentación, una red y un sistema de refrigeración distintos. Si
diseña las soluciones para que utilicen máquinas virtuales replicadas en zonas, podrá proteger sus datos y
aplicaciones frente a la pérdida de un centro de datos. Aunque una zona esté en peligro, las aplicaciones y los datos
replicados estarán disponibles instantáneamente en otra zona.
Obtenga más información acerca de cómo implementar una máquina virtual Windows o Linux en una zona de
disponibilidad.
Dominios de error
Un dominio de error es un grupo lógico de hardware subyacente que comparte la fuente de alimentación y el
conmutador de red, similar a un bastidor dentro de un centro de datos local.
Dominios de actualización
Un dominio de actualización es un grupo lógico de hardware subyacente que puede someterse a mantenimiento o
reiniciarse al mismo tiempo.
Este enfoque garantiza que al menos una instancia de la aplicación sigue ejecutándose cuando se realiza el
mantenimiento periódico de la plataforma Azure. Es posible que el orden en que se reinician los dominios de
actualización no siga una secuencia durante un mantenimiento, pero se reinician de uno en uno.
Conjuntos de escalado de máquinas virtuales

Los conjuntos de escalado de máquinas virtuales de Azure permiten crear y administrar un grupo de máquinas
virtuales con equilibrio de carga. El número de instancias de máquina virtual puede aumentar o disminuir
automáticamente según la demanda, o de acuerdo a una programación definida. Los conjuntos de escalado
proporcionan una alta disponibilidad a las aplicaciones y le permiten administrar, configurar y actualizar de forma
centralizada muchas máquinas virtuales. Se recomienda la creación de dos o más máquinas virtuales en un
conjunto de escalado para proporcionar una aplicación de alta disponibilidad y para cumplir el 99,95 % del
Acuerdo de Nivel de Servicio de Azure. No hay ningún costo asociado con el conjunto de escalado propiamente
dicho, solo se paga por cada instancia de máquina virtual que cree. Cuando una sola máquina virtual usa discos
SSD Premium de Azure, se aplica el Acuerdo de Nivel de Servicio de Azure para los eventos de mantenimiento no
planeados. Las máquinas virtuales de un conjunto de escalado se pueden implementar en varias regiones y
dominios de error para maximizar la disponibilidad y la resistencia a las interrupciones debidas a interrupciones
del centro de datos y a eventos de mantenimiento planeados o no planeados. Las máquinas virtuales de un
conjunto de escalado también se pueden implementar en una sola zona de disponibilidad o en regiones. Las
opciones de implementación de zona de disponibilidad pueden diferir según el modo de orquestación.
Vista previa: versión preliminar del modo de orquestación
Los conjuntos de escalado de máquinas virtuales permiten especificar el modo de orquestación. Con el modo de
orquestación del conjunto de escalado de máquinas virtuales (versión preliminar), ahora puede elegir si el
conjunto de escalado debe orquestar las máquinas virtuales que se crean explícitamente fuera de un modelo de
configuración de conjunto de escalado o las instancias de máquina virtual creadas de manera implícita en función
del modelo de configuración. Elija el modo de orquestación de máquina virtual que le permite agrupar máquinas
virtuales definidas de manera explícita en una región o en una zona de disponibilidad. Las máquinas virtuales
implementadas en una zona de disponibilidad proporcionan aislamiento de zonas a las máquinas virtuales a las
que están enlazadas en el límite de la zona de disponibilidad y no están sujetas a errores que puedan producirse en
otra zona de disponibilidad de la región.
"ORCHESTRATIONMODE": "VM" "ORCHESTRATIONMODE": "SCALESETVM"

(VIRTUALMACHINE) (VIRTUALMACHINESCALESETVM)
Modelo de configuración de máquina Ninguno. VirtualMachineProfile no se Necesario. VirtualMachineProfile se

virtual define en el modelo del conjunto de rellena en el modelo del conjunto de
escalado. escalado.
Incorporación de una máquina virtual Las máquinas virtuales se agregan de Las máquinas virtuales se crean de
nueva a un conjunto de escalado manera explícita al conjunto de escalado manera implícita y se agregan al
cuando se crea la máquina virtual. conjunto de escalado según el modelo
de configuración de la máquina virtual,
el recuento de instancias y las reglas de
escalado automático.
Zonas de disponibilidad Admite la implementación regional o las Admite la implementación regional o

máquinas virtuales en una zona de varias zonas de disponibilidad. Puede
disponibilidad definir la estrategia de equilibrio de
zona.
"ORCHESTRATIONMODE": "VM" "ORCHESTRATIONMODE": "SCALESETVM"
(VIRTUALMACHINE) (VIRTUALMACHINESCALESETVM)
Dominios de error Puede definir el recuento de dominios Puede definir 1, 2 o 3 dominios de error
de error. 2 o 3 según la compatibilidad para implementaciones sin zonas y 5
regional y 5 para la zona de para implementaciones de zonas de
disponibilidad. El dominio de error de disponibilidad. El dominio de error de
VM asignado se conservará con el ciclo VM asignado no se conserva con el
de vida de la máquina virtual, incluida la ciclo de vida de la máquina virtual, a las
desasignación y el reinicio. máquinas virtuales se les asigna un
dominio de error en el momento de la
asignación.
Dominios de actualización N/D Los dominios de actualización se N/D Los dominios de actualización se
asignan automáticamente a los asignan automáticamente a los
dominios de error dominios de error
Dominios de error y dominios de actualización

Los conjuntos de escalado de máquinas virtuales simplifican el diseño para lograr alta disponibilidad al alinear los
dominios de error y los dominios de actualización. Solo tendrá que definir el número de dominios de error del
conjunto de escalado. El número de dominios de error disponibles para los conjuntos de escalado puede variar en
función de la región. Consulte Número de dominios de error por región.
Conjuntos de disponibilidad
Un conjunto de disponibilidad es una agrupación lógica de máquinas virtuales dentro de un centro de datos que
permite a Azure conocer cómo se crea su aplicación para proporcionar redundancia y disponibilidad. Se
recomienda la creación de dos, o más, máquinas virtuales en un conjunto de disponibilidad no solo para
proporcionar una aplicación de alta disponibilidad sino también para cumplir el 99,95 % del Acuerdo de Nivel de
Servicio de Azure. No hay ningún costo asociado con el conjunto de disponibilidad propiamente dicho, solo se
paga por cada instancia de máquina virtual que cree. Cuando una sola máquina virtual usa discos SSD Premium
de Azure, se aplica el Acuerdo de Nivel de Servicio de Azure para los eventos de mantenimiento no planeados.
En un conjunto de disponibilidad, las máquinas virtuales se distribuyen automáticamente entre estos dominios de
error. Este enfoque limita el impacto de potenciales errores de hardware físico, interrupciones de red o cortes de
alimentación eléctrica.
Para las máquinas virtuales que usen Azure Managed Disks, las máquinas virtuales se alinean con los dominios de
error de disco administrado cuando se usa un conjunto de disponibilidad administrada. Esta alineación garantiza
que todos los discos administrados conectados a una máquina virtual se encuentran en el mismo dominio de error
de disco administrado.
Solo se pueden crear máquinas virtuales con discos administrados en un conjunto de disponibilidad administrada.
El número de dominios de error de disco administrado varía según la región: dos o tres dominios de error de disco
administrado por región. Para más información sobre estos dominios de error de Managed Disks consulte
máquinas virtuales Linux o máquinas virtuales Windows.
Las máquinas virtuales dentro de un conjunto de disponibilidad también se distribuyen automáticamente entre los
dominios de actualización.
Pasos siguientes
Ya puede empezar a usar estas características de disponibilidad y redundancia para crear un entorno de Azure.
Para información sobre los procedimientos recomendados, consulte Lista de comprobación de disponibilidad.
Colocación de un recurso para mejorar la latencia
Al implementar la aplicación en Azure, la propagación de instancias entre regiones o zonas de disponibilidad crea
una latencia de red, lo que puede afectar al rendimiento general de la aplicación.
Grupos de selección de ubicación de proximidad

Si coloca las máquinas virtuales en una sola región, reducirá la distancia física entre las instancias. Además, si las
coloca en una sola zona de disponibilidad, estarán todavía más cercanas físicamente. Aun así, a medida que la
superficie de Azure crece, una sola zona de disponibilidad puede abarcar varios centros de datos físicos, lo que es
posible que provoque una latencia de red que puede afectar al rendimiento de la aplicación.
Para acercar las máquinas virtuales lo más posible con la menor latencia posible, debe implementarlas dentro de
un grupo de selección de ubicación de proximidad.
Un grupo de selección de ubicación de proximidad es una agrupación lógica que se usa para asegurarse de que los
recursos de proceso de Azure se encuentran físicamente cercanos entre sí. Los grupos de selección de ubicación de
proximidad son útiles para las cargas de trabajo en las que la latencia baja es un requisito.
Baja latencia entre máquinas virtuales independientes.
Baja latencia entre máquinas virtuales en un único conjunto de disponibilidad o conjunto de escalado de
Baja latencia entre máquinas virtuales independientes, máquinas virtuales en varios conjuntos de disponibilidad
o varios conjuntos de escalado. Puede tener varios recursos de proceso en un solo grupo de selección de
ubicación para reunir una aplicación de varias capas.
Baja latencia entre varias capas de aplicación con diferentes tipos de hardware. Por ejemplo, la ejecución del
back-end con la serie M en un conjunto de disponibilidad y el front-end en una instancia de la serie D, en un
conjunto de escalado, en un solo grupo de selección de ubicación de proximidad.
Uso de los grupos de selección de ubicación de proximidad
Un grupo de selección de ubicación de proximidad es un nuevo tipo de recurso de Azure. Debe crear uno para
poder usarlo con otros recursos. Una vez creado, podría usarse con máquinas virtuales, conjuntos de
disponibilidad o conjuntos de escalado de máquinas virtuales. Un grupo de selección de ubicación de proximidad
se especifica al crear recursos de proceso que proporcionan el identificador de grupo de selección de ubicación de
proximidad.
También puede mover un recurso existente a un grupo de selección de ubicación de proximidad. Al hacerlo, debe
detener (desasignar) el recurso en primer lugar, ya que se volverá a implementar posiblemente en otro centro de
datos de la región para satisfacer la restricción de colocación.
En el caso de conjuntos de disponibilidad y conjuntos de escalado de máquinas virtuales, debe establecer el grupo
de selección de ubicación de proximidad en el nivel de recursos, en lugar de en las máquinas virtuales individuales.
Un grupo de selección de ubicación de proximidad es una restricción de colocación y no un mecanismo de anclaje.
Se ancla a un centro de datos específico con la implementación del primer recurso para usarlo. Una vez que todos
los recursos que usan el grupo de selección de ubicación de proximidad se han detenido (desasignado) o
eliminado, ya no se anclan. Por lo tanto, cuando se usa un grupo de selección de ubicación de proximidad con
varias series de máquinas virtuales, es importante especificar todos los tipos necesarios al principio en una plantilla
cuando sea posible o seguir una secuencia de implementación, lo que mejorará las oportunidades de una
implementación correcta. Si se produce un error en la implementación, reinicie esta con el tamaño de máquina
virtual que ha dado error como el primer tamaño que se va a implementar.
Procedimientos recomendados
Para la latencia más baja, use grupos de selección de ubicación de proximidad junto con redes aceleradas. Para
obtener más información, consulte Creación de una máquina virtual Linux con redes aceleradas o Creación de
una máquina virtual Windows con redes aceleradas.
Implemente todos los tamaños de máquina virtual en una sola plantilla. Para evitar llegar a hardware que no
admite todas las SKU y tamaños de máquina virtual que necesita, incluya todas las capas de aplicación en una
sola plantilla de modo que se implementen todas al mismo tiempo.
Si va a crear scripts de la implementación mediante PowerShell, la CLI o el SDK, puede producirse un error de
asignación OverconstrainedAllocationRequest . En este caso, debe detener o desasignar todas las máquinas
virtuales existentes y cambiar la secuencia en el script de implementación para que empiece con la SKU o los
tamaños de máquina virtual en los que se produjo el error.
Al reutilizar un grupo de selección de ubicación existente del que se han eliminado máquinas virtuales, espere a
que la eliminación se complete antes de agregarle máquinas virtuales.
Si su prioridad es la latencia, coloque las máquinas virtuales en un grupo de selección de ubicación de
proximidad y toda la solución en una zona de disponibilidad. En cambio, si su prioridad es la resistencia,
distribuya las instancias por varias zonas de disponibilidad (un solo grupo de selección de ubicación de
proximidad no puede abarcar zonas).
Pasos siguientes
Implemente una máquina virtual en un grupo de selección de ubicación de proximidad mediante Azure
PowerShell.
Aprenda a probar la latencia de red.
Aprenda a optimizar el rendimiento de la red.
Aprenda a usar grupos de selección de ubicación de proximidad con las aplicaciones de SAP.
Optimización del rendimiento de red en las
máquinas virtuales de Azure
Las máquinas virtuales de Azure (VM ) tienen una configuración de red predeterminada que se puede optimizar
para mejorar aún más el rendimiento de la red. En este artículo se describe cómo optimizar el rendimiento de la
red de las máquinas virtuales Windows y Linux de Microsoft Azure, incluidas las distribuciones principales como
Ubuntu, CentOS y Red Hat.
Máquina virtual de Windows

Si la máquina virtual Windows es compatible con redes aceleradas, habilite esta característica para conseguir un
rendimiento óptimo. En el caso de otras máquinas virtuales Windows, el uso de escalado en el lado de la
recepción (RSS ) pueden logar un rendimiento máximo mayor que las que no lo usan. En las máquinas virtuales
Windows, RSS se puede deshabilitar de forma predeterminada. Para determinar si RSS está habilitado y para
habilitarlo si no lo está en la actualidad, complete los siguientes pasos:
1. Compruebe si RSS está habilitado para un adaptador de red con el comando Get-NetAdapterRss de
PowerShell. En la siguiente salida de ejemplo que devuelve Get-NetAdapterRss , RSS no está habilitado.
Name : Ethernet
InterfaceDescription : Microsoft Hyper-V Network Adapter
Enabled : False
2. Para habilitar RSS escriba el siguiente comando:
Get-NetAdapter | % {Enable-NetAdapterRss -Name $_.Name}
El comando anterior no tiene ninguna salida. El comando cambió la configuración de NIC, lo que ha
provocado una pérdida temporal de la conectividad durante aproximadamente un minuto. Durante la
pérdida de conectividad aparece un cuadro de diálogo de reconexión. La conectividad se suele restaurar al
tercer intento.
3. Confirme que RSS está habilitado en la máquina virtual, para lo que debe volver a escribir el comando
Get-NetAdapterRss . Si se realiza correctamente, se devuelve la siguiente salida de ejemplo:
Name : Ethernet
InterfaceDescription : Microsoft Hyper-V Network Adapter
Enabled : True
Máquina virtual de Linux

De manera predeterminada, en las máquinas virtuales Linux de Azure RSS está siempre habilitado. Los kernels
de Linux lanzados desde octubre de 2017 incluyen nuevas opciones de optimización de red que permiten que las
máquinas virtuales Linux logren un mayor rendimiento de la red.
Ubuntu para las nuevas implementaciones
El kernel de Azure de Ubuntu proporciona el mejor rendimiento de la red en Azure y ha sido el kernel
predeterminado desde el 21 de septiembre de 2017. Para obtener este kernel, primero instale la última versión
compatible de 16.04-LTS, como se describe a continuación:
"Publisher": "Canonical",
"Offer": "UbuntuServer",
"Sku": "16.04-LTS",
"Version": "latest"
Una vez que la creación finaliza, escriba los siguientes comandos para obtener el actualizaciones más recientes.
Estos pasos también funcionan en las máquinas virtuales que ejecutan actualmente el kernel de Azure de
Ubuntu.
#run as root or preface with sudo

apt-get -y update
apt-get -y upgrade
apt-get -y dist-upgrade
El siguiente conjunto de comandos opcional puede ser útil para las implementaciones de Ubuntu existentes que
ya tiene el kernel de Azure, pero que no han podido realizar actualizaciones debido a errores.
#optional steps may be helpful in existing deployments with the Azure kernel
apt-get -f install
apt-get --fix-missing install
apt-get clean
apt-get -y update
apt-get -y upgrade
apt-get -y dist-upgrade
Actualización del kernel de Azure de Ubuntu para las máquinas virtuales existentes
Se puede lograr un rendimiento significativo instalando el kernel de Linux de Azure propuesto. Para comprobar
si tienen este kernel, compruebe la versión del kernel.
#Azure kernel name ends with "-azure"

uname -r
#sample output on Azure kernel:

#4.13.0-1007-azure
Si la máquina virtual no tiene el kernel de Azure, el número de versión comenzará normalmente con "4.4." Si la
máquina virtual no tiene el kernel de Azure, ejecute los comandos siguientes como raíz:

apt-get update
apt-get upgrade -y
apt-get dist-upgrade -y
apt-get install "linux-azure"
reboot
CentOS
Para obtener las optimizaciones más recientes, se recomienda crear una máquina virtual con la versión más
reciente compatible mediante la especificación de los siguientes parámetros:
"Publisher": "OpenLogic",
"Offer": "CentOS",
"Sku": "7.4",
"Version": "latest"
Tanto las máquinas virtuales nuevas como las existentes se pueden beneficiar de la versión más reciente de Linux
Integration Services (LIS ). La optimización del rendimiento es en LIS, a partir de 4.2.2-2, aunque las versiones
posteriores contienen más mejoras. Escriba los siguientes comandos para instalar el LIS más reciente:
sudo yum update

sudo reboot
sudo yum install microsoft-hyper-v
Red Hat
Para obtener las optimizaciones, se recomienda crear una máquina virtual con la versión más reciente
compatible mediante la especificación de los siguientes parámetros:
"Publisher": "RedHat"
"Offer": "RHEL"
"Sku": "7-RAW"
"Version": "latest"
Tanto las máquinas virtuales nuevas como las existentes se pueden beneficiar de la versión más reciente de Linux
Integration Services (LIS ). La optimización del rendimiento se realiza en LIS a partir de la versión 4.2. Escriba los
siguientes comandos para descargar e instalar LIS:
mkdir lis4.2.3-5
cd lis4.2.3-5
wget https://download.microsoft.com/download/6/8/F/68FE11B8-FAA4-4F8D-8C7D-74DA7F2CFC8C/lis-rpms-4.2.3-
5.tar.gz
tar xvzf lis-rpms-4.2.3-5.tar.gz
cd LISISO
install.sh #or upgrade.sh if prior LIS was previously installed
Para más información sobre la versión 4.2 de Linux Integration Services para Hyper-V, vea la página de
descarga.
Pasos siguientes
Vea el resultado con las pruebas de ancho de banda y rendimiento de Azure VM para su escenario.
Obtenga información acerca de cómo se asigna el ancho de banda a las máquinas virtuales
Obtenga más información con las Preguntas más frecuentes (P+F ) acerca de Azure Virtual Network
Tamaños de las máquinas virtuales Windows en
Azure
En este artículo se describen los tamaños y las opciones disponibles para las máquinas virtuales de Azure
que puede usar para ejecutar las aplicaciones y cargas de trabajo de Windows. También ofrece
consideraciones de implementación que hay que tener en cuenta siempre que planee usar estos recursos.
Este artículo también está disponible para máquinas virtuales Linux.
TYPE TAMAÑOS DESCRIPCIÓN
Uso general B, Dsv3, Dv3, Dasv4, Dav4, DSv2, Uso equilibrado de la CPU en
Dv2, Av2, DC proporción de memoria. Ideal para
desarrollo y pruebas, bases de datos
pequeñas o medianas, y servidores
web de tráfico bajo o medio.
Proceso optimizado Fsv2 Uso elevado de la CPU en

proporción de memoria. Bueno para
servidores web de tráfico medio,
aplicaciones de red, procesos por
lotes y servidores de aplicaciones.
Memoria optimizada Esv3, Ev3, Easv4, Eav4, Mv2, M, Memoria alta en proporción de CPU.
DSv2, Dv2 Excelente para servidores de bases
de datos relacionales, memorias
caché de capacidad media o grande
y análisis en memoria.
Almacenamiento optimizado Lsv2 Alto rendimiento de disco y de E/S

ideales para macrodatos, bases de
datos SQL y NoSQL,
almacenamiento de datos y bases de
datos transaccionales grandes.
GPU NC, NCv2, NCv3, ND, NDv2 (versión Máquinas virtuales especializadas
preliminar), NV, NVv3 específicas para la representación de
gráficos pesados y la edición de
vídeo, así como para el
entrenamiento e inferencia de
modelos (ND) con aprendizaje
profundo. Están disponibles con uno
o varios GPU.
Proceso de alto rendimiento HB, HC, H Nuestras máquinas virtuales de CPU

más rápidas y eficaces con interfaces
de red de alto rendimiento
opcionales (RDMA).
Para obtener información sobre los precios de los diferentes tamaños, consulte Precios de máquinas
virtuales.
Para ver los límites generales de las máquinas virtuales de Azure, consulte Límites, cuotas y
restricciones de suscripción y servicios de Microsoft Azure.
Los costes de almacenamiento se calculan por separado según las páginas utilizadas en la cuenta de
almacenamiento. Para obtener más información, consulte Precios de Azure Storage.
Obtenga más información sobre cómo las unidades de proceso de Azure (ACU ) pueden ayudarlo a
comparar el rendimiento en los distintos SKU de Azure.
API DE REST
Para obtener información sobre el uso de la API de REST para consultar los tamaños de máquina virtual,
consulte lo siguiente:
Lista de tamaños de máquina virtual disponibles para cambio de tamaño
Lista de tamaños de máquina virtual disponibles para una suscripción
Lista de tamaños de máquina virtual disponibles en un conjunto de disponibilidad
ACU
Puntuaciones de pruebas comparativas

Más información sobre el rendimiento de los procesos para las máquinas virtuales Windows con las
puntuaciones de pruebas comparativas de CoreMark.
Pasos siguientes
Obtenga más información sobre los diferentes tamaños de máquina virtual que están disponibles:
Uso general
Proceso optimizado
Memoria optimizada
GPU optimizada
Proceso de alto rendimiento
Consulte la página Generación anterior para las series A estándar, Dv1 (D1-4 y D11-14 v1) y las series
A8-A11
Compatibilidad para máquinas virtuales de
generación 2 en Azure
La compatibilidad para las máquinas virtuales (VM ) de generación 2 ahora está disponible en Azure. No se puede
cambiar la generación de una máquina virtual después de haberla creado, así que revise las consideraciones de
esta página antes de elegir una generación.
Las máquinas virtuales de generación 2 admiten características clave que no se admiten en las VM de generación
1. Estas características incluyen una memoria mayor, Intel Software Guard Extensions (SGX Intel) y memoria
persistente virtualizada (vPMEM ). Las VM de generación 2 que se ejecutan en el entorno local también tienen
algunas características que aún no se admiten en Azure. Para obtener más información, consulte la sección
Características y funcionalidades.
Las VM de generación 2 usan la nueva arquitectura de arranque basado en UEFI en lugar de la arquitectura
basada en BIOS que utilizan las VM de generación 1. En comparación con las VM de generación 1, es posible las
de generación 2 tengan tiempos de arranque e instalación mejorados. Para obtener una visión general de las VM
de generación 2 y algunas de las diferencias entre la generación 1 y la generación 2, consulte ¿Debo crear una
máquina virtual de generación 1 o 2 en Hyper-V?
Tamaños de VM de generación 2
Las VM de generación 1 son compatibles con todos los tamaños de máquina virtual en Azure. Azure ahora ofrece
compatibilidad de generación 2 para las siguientes series de VM seleccionadas:
Serie B
Serie DC
Serie Dsv2 y serie Dsv3
Serie Esv3
Serie Fsv2
Serie GS
Serie HB
Serie HC
Serie Ls y serie Lsv2
Serie Mv2
Serie NCv2 y serie NCv3
Serie ND
Serie NVv3
NOTE
El uso de imágenes de máquina virtual de generación 2 en las máquinas virtuales de la serie Mv2 está disponible con
carácter general, ya que esta serie funciona exclusivamente con imágenes de máquina virtual de generación 2. Las imágenes
de máquina virtual de generación 1 no se admiten en máquinas virtuales de la serie Mv2.
Imágenes de VM de generación 2 en Azure Marketplace

Las VM de generación 2 admiten las siguientes imágenes de Marketplace:
Windows Server 2019 Datacenter
Windows Server 2012 R2 Datacenter
SUSE Linux Enterprise Server 15 SP1
SUSE Linux Enterprise Server 12 SP4
Ubuntu Server 16.04, 18.04, 19,04, 19,10
RHEL 8.0
Máquinas virtuales locales frente a VM de generación 2 de Azure

Actualmente Azure no admite algunas de las características que admite Hyper-V en el entorno local para VM de
generación 2.
CARACTERÍSTICAS DE LA GENERACIÓN 2 HYPER-V LOCAL AZURE
Arranque seguro ✔
VM Blindada ✔
vTPM ✔
Seguridad basada en virtualización ✔

(VBS)
Formato VHDX ✔
Características y funcionalidades
Características de la generación 1 frente a la generación 2
CARACTERÍSTICA GENERACIÓN 1 GENERACIÓN 2
Arranque PCAT UEFI
Controladoras de disco IDE SCSI
Tamaños de VM Todos los tamaños de VM Solo las VM que admiten Premium

Storage
Funcionalidades de la generación 1 frente a la generación 2

CAPACIDAD GENERACIÓN 1 GENERACIÓN 2
Disco de SO > 2 TB ✔
Disco ✔ ✔
personalizado/imagen/intercambiar SO
Compatibilidad con los conjuntos de ✔ ✔

escalado de máquinas virtuales
CAPACIDAD GENERACIÓN 1 GENERACIÓN 2
Azure Site Recovery ✔ ✔
Copia de seguridad y restauración ✔ ✔
Galería de imágenes compartidas ✔ ✔
Azure Disk Encryption ✔
Creación de una VM de generación 2

Imagen de Marketplace
En Azure Portal o la CLI de Azure, puede crear VM de generación 2 a partir de una imagen de Marketplace que
admita el arranque UEFI.
Portal de Azure
Las imágenes de la generación 2 para Windows y SLES se incluyen en la misma oferta de servidor que las
imágenes de Generación 1. Lo que eso significa desde una perspectiva de flujo, es que selecciona la oferta y el
SKU del portal para la máquina virtual. Si la SKU admite tanto imágenes de la generación 1 como de la
generación 2, puede optar por crear una máquina virtual de la generación 2 desde la pestaña Avanzado en el flujo
de creación de la máquina virtual.
Actualmente, las SKU siguientes admiten imágenes de la generación 1 y de la generación 2:
Windows Server 2012
Windows Server 2012 R2
Windows Server 2016
Windows Server 2019
Al seleccionar una SKU de Windows Server como oferta, en la pestaña Avanzado, hay una opción para crear una
máquina virtual Generación 1 (BIOS ) o Generación 2 (UEFI). Si selecciona Gen 2, asegúrese de que el tamaño
de la máquina virtual seleccionado en la pestaña Datos básicos se admite para máquinas virtuales de la
generación 2.
PowerShell
También puede usar PowerShell para crear una máquina virtual haciendo referencia directamente a la SKU de
generación 1 o de generación 2.
Por ejemplo, use el siguiente cmdlet de PowerShell para obtener una lista de las SKU de la oferta WindowsServer .
Get-AzVMImageSku -Location westus2 -PublisherName MicrosoftWindowsServer -Offer WindowsServer
Si va a crear una máquina virtual con Windows Server 2012 como sistema operativo, seleccione la SKU de
máquina virtual de generación 1 (BIOS ) o de generación 2 (UEFI), que tiene un aspecto similar al siguiente:
2012-Datacenter
2012-datacenter-gensecond
Consulte la sección Características y funcionalidades para obtener una lista de imágenes compatibles de
Marketplace.
Imagen administrada o disco administrado
Puede crear una VM de generación 2 desde una imagen administrada o un disco administrado de la misma
manera que crearía una VM de generación 1.
También puede crear VM de generación 2 usando conjuntos de escalado de VM. En la CLI de Azure, use los
conjuntos de escalado de Azure para crear VM de generación 2.

¿Están disponibles las máquinas virtuales de generación 2 en todas las regiones de Azure?
Sí. Pero no todos los tamaños de VM de generación 2 están disponibles en todas las regiones. La
disponibilidad de las VM de generación 2 depende de la disponibilidad del tamaño de máquina virtual.
¿Hay diferencia de precio entre las VM de generación 1 y de generación 2?
No.
Tengo un archivo .vhd de mi VM de generación 2 local. ¿Puedo usar ese archivo .vhd para crear
una VM de generación 2 en Azure? Sí, puede llevar el archivo .vhd de generación 2 a Azure y usarlo para
crear una VM de generación 2. Para ello, siga estos pasos:
1. Cargue el archivo . vhd en una cuenta de almacenamiento en la misma región en la que quiere crear
la VM.
2. Cree un disco administrado a partir del archivo .vhd. Establezca la propiedad de generación de
Hyper-V en V2. Los siguientes comandos de PowerShell establecen la propiedad de generación de
Hyper-V al crear el disco administrado.
$sourceUri = 'https://xyzstorage.blob.core.windows.net/vhd/abcd.vhd'. #<Provide location to your

uploaded .vhd file>
$osDiskName = 'gen2Diskfrmgenvhd' #<Provide a name for your disk>
$diskconfig = New-AzDiskConfig -Location '<location>' -DiskSizeGB 127 -AccountType Standard_LRS -
OsType Windows -HyperVGeneration "V2" -SourceUri $sourceUri -CreateOption 'Import'
New-AzDisk -DiskName $osDiskName -ResourceGroupName '<Your Resource Group>' -Disk $diskconfig
3. Una vez que el disco esté disponible, cree una VM mediante la conexión de este disco. La VM creada
será de generación 2. Cuando se crea la VM de generación 2, puede generalizar la imagen de esta
VM de forma opcional. Al generalizar la imagen, puede usarla para crear varias máquinas virtuales.
¿Cómo se puede aumentar el tamaño del disco del SO?
Los discos del SO mayores de 2 TB son nuevos en las máquinas virtuales de generación 2. De forma
predeterminada, los discos del SO son menores que 2 TB para las máquinas virtuales de generación 2.
Puede aumentar el tamaño del disco hasta un máximo recomendado de 4 TB. Use la CLI de Azure o Azure
Portal para aumentar el tamaño del disco del SO. Para obtener información sobre cómo expandir los discos
mediante programación, vea Cómo ampliar la unidad de sistema operativo de una máquina virtual.
Para aumentar el tamaño del disco del SO desde Azure Portal:
1. En Azure Portal, vaya a la página de propiedades de la máquina virtual.
2. Para apagar y desasignar la VM, haga clic en el botón Detener.
3. En la sección Discos, seleccione el disco del SO que quiere aumentar.
4. En la sección Discos, seleccione Configuración y actualice el Tamaño con el valor que quiera.
5. Vuelva a la página de propiedades de la máquina virtual e inicie la VM.
Es posible que vea una advertencia para los discos del SO mayores de 2 TB. La advertencia no se aplica a
las máquinas virtuales de generación 2. Pero no se recomiendan los tamaños de disco del SO de más de 4
TB.
¿Las VM de generación 2 admiten las redes aceleradas?
Sí. Para más información vea Creación de una máquina virtual con redes aceleradas.
¿Admite la generación 2 VHDX?
No, las VM de generación 2 solo admiten VHD.
¿Las máquinas virtuales de generación 2 admiten Almacenamiento en disco Ultra de Azure?
Sí.
¿Puedo migrar una VM de generación 1 a la generación 2?
No, no se puede cambiar la generación de una VM después de crearla. Si tiene que cambiar entre varias
generaciones de VM, cree una nueva máquina virtual de otra generación.
Pasos siguientes
Obtenga información sobre las VM de generación 2 en Hyper-V.
Obtenga información sobre cómo preparar un disco duro virtual para cargar desde sistemas locales a
Azure.
Tamaños de máquina virtual de uso general
Los tamaños de VM de uso general proporcionan una relación equilibrada entre CPU y memoria. Ideal para
desarrollo y pruebas, bases de datos pequeñas o medianas, y servidores web de tráfico bajo o medio. En este
artículo, se proporciona información acerca del número de vCPU, discos de datos y tarjetas de interfaz de red,
así como del rendimiento del almacenamiento para cada tamaño de esta agrupación.
La serie DC es una familia de máquinas virtuales de Azure que puede ayudar a proteger la
confidencialidad y la integridad de los datos y del código mientras se están procesando en la nube
pública. Estas máquinas están respaldadas por la última generación del procesador Intel XEON E -2176G
a 3,7 GHz con la tecnología SGX. Con la tecnología Intel Turbo Boost, estas máquinas pueden llegar hasta
4,7 GHz. Las instancias de la serie DC permiten a los clientes crear aplicaciones seguras basadas en
enclave para proteger sus datos y código mientras se usan.
Las máquinas virtuales de la serie Av2 se pueden implementar en diversos procesadores y tipos de
hardware. Las máquinas virtuales de la serie A tienen las configuraciones de memoria y rendimiento de
CPU adecuadas para cargas de trabajo de nivel de entrada como desarrollo y pruebas. Según el
hardware, el tamaño es una limitación para ofrecer un rendimiento coherente del procesador para la
instancia en ejecución, independientemente del hardware en que se implementó. Con el fin de determinar
el hardware físico en que se implementó este tamaño, cree una consulta para el hardware virtual desde
dentro de la máquina virtual.
Algunos casos de uso son, por ejemplo, los servidores de desarrollo y pruebas, los servidores web con
poco tráfico, las bases de datos de tamaño pequeño a mediano, las pruebas de concepto y los repositorios
de código.
La serie Dv2, una continuación de la serie D original, presenta una CPU más potente y una configuración
óptima de la CPU a la memoria, lo que la hace adecuada para la mayoría de las cargas de trabajo de
producción. La serie Dv2 es un 35 % aproximadamente más rápida que la serie D. La serie Dv2 se ejecuta
en procesadores Intel® Xeon® 8171M 2.1 GHz (Skylake), Intel® Xeon® E5-2673 v4 2.3 GHz
(Broadwell) o Intel® Xeon® E5-2673 v3 2.4 GHz (Haswell) con Intel Turbo Boost Technology 2.0. La
serie Dv2 tiene las mismas configuraciones de disco y memoria que la serie D.
La serie Dv3 se ejecuta en procesadores Intel® Xeon® 8171M 2.1 GHz (Skylake), Intel® Xeon® E5-
2673 v4 2.3 GHz (Broadwell) o Intel® Xeon® E5-2673 v3 2.4 GHz (Haswell) en una configuración de
Hyper-Threading, lo que proporciona una mejor propuesta de valor para la mayoría de las cargas de
trabajo de uso general. Se ha ampliado la memoria (de ~3,5 GiB/vCPU a 4 GiB/vCPU ), y los límites de
disco y red se han ajustado por núcleo para equipararse con el cambio a hyperthreading. La serie Dv3 ya
no tiene los tamaños de máquina virtual de memoria alta de la serie D/Dv2, que se han pasado a la serie
Ev3 optimizada para memoria para Windows y Linux .
Algunos casos de uso de la serie D son las aplicaciones empresariales, las bases de datos relacionales, el
almacenamiento en caché en memoria y el análisis.
Las series Dav4 y Dasv4 son tamaños nuevos que utilizan el procesador EPYC TM 7452 de 2,35 Ghz de
AMB en una configuración de varios subprocesos con una caché L3 de hasta 256 GB que dedica 8 GB de
esa caché L3 a cada 8 núcleos, lo que aumenta las opciones que tiene el cliente de ejecutar sus cargas de
trabajo de uso general. Las series Dav4 y Dasv4 tienen las mismas configuraciones de memoria y disco
que las series D y Dsv3.
Serie B
Premium Storage: Compatible
Almacenamiento en caché de Premium Storage: No compatible
Las máquinas virtuales ampliables de la serie B son idóneas para cargas de trabajo que no necesitan un
rendimiento completo de la CPU de forma continua, como los servidores web, pequeñas bases de datos y
entornos de desarrollo y de prueba. Estas cargas de trabajo suelen necesitar unos requisitos de rendimiento
ampliables. La serie B ofrece a estos clientes la posibilidad de comprar un tamaño de máquina virtual con un
rendimiento base sensible al precio y que permita a la instancia de la máquina virtual acumular crédito cuando
su rendimiento sea inferior al rendimiento base. Cuando la máquina virtual ha acumulado crédito se puede
ampliar por encima de la base de referencia de esta con un uso de hasta un 100% de la CPU si la aplicación
necesita el mayor rendimiento posible.
Algunos casos de uso son, por ejemplo, los servidores de desarrollo y pruebas, los servidores web con poco
tráfico, las bases de datos pequeñas, los servidores para pruebas de concepto y los servidores de compilación.
REND REND
IMIEN IMIEN
TO TO
MÁXI MÁXI
MO MO
DE DEL
REND ALMA DISC
REND IMIEN CENA O SIN
IMIEN TO MIEN ALMA
GIB TO MÁXI TO CENA
DE BASE MO TEMP MIEN
ALMA DE DE CRÉDI ORAL TO EN
CENA CPU CPU CRÉDI TOS Y EN LA
MIEN DE LA DE LA TOS MÁXI DISC CACH CACH
TO MÁQ MÁQ CRÉDI INGR MOS OS DE É: É:
MEM TEMP UINA UINA TOS ESAD INGR DATO IOPS IOPS Nº
ORIA: ORAL VIRT VIRT INICI OS / ESAD S / / MÁX.
SIZE VCPU GIB (SSD) UAL UAL ALES HORA OS MÁX. MBPS MBPS NIC
Stan 1 0,5 4 5% 100 30 3 72 2 200/ 160/ 2

dard % 10 10
_B1ls
1
Stan 1 1 4 10% 100 30 6 144 2 400 / 320 / 2

dard % 10 10
_B1s
Stan 1 2 4 20% 100 30 12 288 2 800 / 640 / 2

dard % 10 10
_B1
ms
Stan 2 4 8 40% 200 60 24 576 4 1600 1280 3

dard % / 15 / 15
_B2s
Stan 2 8 16 60% 200 60 36 864 4 2400 1920 3

dard % / /
_B2 22.5 22.5
ms
REND REND
IMIEN IMIEN
TO TO
MÁXI MÁXI
MO MO
DE DEL
REND ALMA DISC
REND IMIEN CENA O SIN
IMIEN TO MIEN ALMA
GIB TO MÁXI TO CENA
DE BASE MO TEMP MIEN
ALMA DE DE CRÉDI ORAL TO EN
CENA CPU CPU CRÉDI TOS Y EN LA
MIEN DE LA DE LA TOS MÁXI DISC CACH CACH
TO MÁQ MÁQ CRÉDI INGR MOS OS DE É: É:
MEM TEMP UINA UINA TOS ESAD INGR DATO IOPS IOPS Nº
ORIA: ORAL VIRT VIRT INICI OS / ESAD S / / MÁX.
Stan 4 16 32 90% 400 120 54 1296 8 3600 2880 4

dard % / 35 / 35
_B4
ms
Stan 8 32 64 135 800 240 81 1944 16 4320 4320 4

dard % % / 50 / 50
_B8
ms
Stan 12 48 96 202 1200 360 121 2909 16 6480 4320 6

dard % % / 75 / 50
_B12
ms
Stan 16 64 128 270 1600 480 162 3888 32 8640 4320 8

dard % % / 100 / 50
_B16
ms
Stan 20 80 160 337 2000 600 203 4860 32 1080 4320 8

dard % % 0/ / 50
_B20 125
ms
1 B1ls solo se admite en Linux
Serie Dsv3 1
ACU: 160-190
Almacenamiento en caché de Premium Storage: Compatible
Los tamaños de la serie Dsv3 se ejecutan en procesadores Intel® Xeon® 8171M 2.1 GHz (Skylake), Intel®
Xeon® E5-2673 v4 2.3 GHz (Broadwell) o Intel® Xeon® E5-2673 v3 2.4 GHz (Haswell) con Intel Turbo Boost
Technology 2.0 y usan Premium Storage. Los tamaños de la serie Dsv3 ofrecen una combinación de vCPU,
memoria y almacenamiento local adecuados para la mayoría de las cargas de trabajo de producción.
RENDIMIENT
O MÁXIMO
DE
ALMACENA RENDIMIENT
MIENTO O MÁXIMO
TEMPORAL Y DEL DISCO Nº MÁX. DE
GIB DE EN CACHÉ: SIN NIC/ANCHO
ALMACENA IOPS / MBPS ALMACENA DE BANDA
MIENTO DISCOS DE (TAMAÑO MIENTO EN DE RED
MEMORIA: TEMPORAL DATOS DE CACHÉ EN LA CACHÉ: ESPERADO
SIZE VCPU GIB (SSD) MÁX. GIB) IOPS / MBPS (MBPS)
Standard_D 2 8 16 4 4000/32 3200/48 2 / 1000

2s_v3 (50)
Standard_D 4 16 32 8 8000/64 6400/96 2 / 2000

4s_v3 (100)
Standard_D 8 32 64 16 16000/128 12800/192 4/4000

8s_v3 (200)
Standard_D 16 64 128 32 32000/256 25600/384 8 / 8000

16s_v3 (400)
Standard_D 32 128 256 32 64000/512 51200/768 8 / 16000

32s_v3 (800)
Standard_D 48 192 384 32 96000 / 76800 / 8 / 24000

48s_v3 768 (1200) 1152
Standard_D 64 256 512 32 128000/10 80000/120 8 / 30 000

64s_v3 24 (1600) 0
1 Las máquinas virtuales de la serie Dsv3 cuentan con la tecnología Hyper-Threading de Intel®.
Serie Dasv4
ACU: 230-260
Los tamaños de la serie Dasv4 se basan en el procesador EPYC TM 7452 de AMD de 2,35 Ghz que pueden
alcanzar una frecuencia máxima incrementada de 3,35 Ghz y usar SSD Premium. Los tamaños de la serie Dasv4
ofrecen una combinación de vCPU, memoria y almacenamiento local adecuados para la mayoría de las cargas
de trabajo de producción.
RENDIMIENT
O MÁXIMO
DE
ALMACENA RENDIMIENT
MIENTO O MÁXIMO
GIB DE EN CACHÉ: SIN NIC / ANCHO
Standard_D 2 8 16 4 4000/32 3200/48 2 / 1000

2as_v4 (50)
RENDIMIENT
O MÁXIMO
DE
ALMACENA RENDIMIENT
MIENTO O MÁXIMO
Standard_D 4 16 32 8 8000/64 6400/96 2 / 2000

4as_v4 (100)
Standard_D 8 32 64 16 16000/128 12800/192 4/4000

8as_v4 (200)
Standard_D 16 64 128 32 32 000 / 25600/384 8 / 8000

16as_v4 255 (400)
Standard_D 32 128 256 32 64 000 / 51200/768 8 / 16000

32as_v4 510 (800)
Standard_D 48 192 384 32

48as_v4 **
Standard_D 64 256 512 32

64as_v4 **
Standard_D 96 384 768 32

96as_v4 **
**Estos tamaños se encuentran en versión preliminar. Si está interesado en probar estos tamaños más grandes,
regístrese en https://aka.ms/AzureAMDLargeVMPreview.
Serie Dv3 1
ACU: 160-190
Premium Storage: No compatible
Los tamaños de la serie Dv3 se ejecutan en procesadores Intel® Xeon® 8171M 2.1 GHz (Skylake), Intel®
Technology 2.0. Los tamaños de la serie Dv3 ofrecen una combinación de vCPU, memoria y almacenamiento
local adecuados para la mayoría de las cargas de trabajo de producción.
El almacenamiento en disco de datos se factura de forma independiente a las máquinas virtuales. Para usar
discos de Premium Storage, utilice los tamaños Dsv3. El precio y los medidores de facturación para los tamaños
Dsv3 son los mismos que para la serie Dv3.
RENDIMIENTO
MÁXIMO DE
ALMACENAMIE
NTO
GIB DE TEMPORAL:
ALMACENAMIE IOPS / MBPS
NTO DE LECTURA / ANCHO DE
TEMPORAL DISCOS DE MBPS DE BANDA DE
TAMAÑO VCPU MEMORIA: GIB (SSD) DATOS MÁX. ESCRITURA RED/NIC MÁX.
Standard_D2_ 2 8 50 4 3000/46/23 2 / 1000

v3
Standard_D4_ 4 16 100 8 6000/93/46 2 / 2000

v3
Standard_D8_ 8 32 200 16 12000/187/9 4/4000

v3 3
Standard_D1 16 64 400 32 24000/375/1 8 / 8000

6_v3 87
Standard_D3 32 128 800 32 48000/750/3 8 / 16000

2_v3 75
Standard_D4 48 192 1200 32 96000/1000/ 8 / 24000

8_v3 500
Standard_D6 64 256 1600 32 96000/1000/ 8 / 30 000

4_v3 500
1 Las máquinas virtuales de la serie Dv3 cuentan con la tecnología Hyper-Threading de Intel®.
Serie Dav4
ACU: 230-260
Los tamaños de la serie Dav4 se basan en el procesador EPYC TM 7452 de AMD de 2,35 Ghz que pueden
alcanzar una frecuencia máxima incrementada de 3,35 Ghz. Los tamaños de la serie Dav4 ofrecen una
combinación de vCPU, memoria y almacenamiento local adecuados para la mayoría de las cargas de trabajo de
producción. El almacenamiento en disco de datos se factura de forma independiente a las máquinas virtuales.
Para usar SSD Premium, use los tamaños de Dasv4. El precio y los medidores de facturación para los tamaños
Dasv4 son los mismos que para la serie Dav4.
RENDIMIENTO
MÁXIMO DE
ALMACENAMIE
NTO
GIB DE TEMPORAL: Nº MÁX. DE
ALMACENAMIE IOPS / MBPS NIC / ANCHO
NTO DE LECTURA / DE BANDA DE
TEMPORAL DISCOS DE MBPS DE RED ESPERADO
SIZE VCPU MEMORIA: GIB (SSD) DATOS MÁX. ESCRITURA (MBPS)
Standard_D2a 2 8 50 4 3000 / 46 / 2 / 1000

_v4 23
RENDIMIENTO
MÁXIMO DE
ALMACENAMIE
NTO
ALMACENAMIE IOPS / MBPS NIC / ANCHO
NTO DE LECTURA / DE BANDA DE
TEMPORAL DISCOS DE MBPS DE RED ESPERADO
Standard_D4a 4 16 100 8 6000 / 93 / 2 / 2000

_v4 46
Standard_D8a 8 32 200 16 12000 / 187 / 4/4000

_v4 93
Standard_D1 16 64 400 32 24000 / 375 / 8 / 8000

6a_v4 187
Standard_D3 32 128 800 32 48000 / 750 / 8 / 16000

2a_v4 375
Standard_D4 48 192 1200 32

8a_v4 **
Standard_D6 64 256 1600 32

4a_v4 **
Standard_D9 96 384 2400 32

6a_v4 **
DSv2-series
ACU: 210-250
Los tamaños de la serie DSv2 se ejecutan en procesadores Intel® Xeon® 8171M 2.1 GHz (Skylake), Intel®
Technology 2.0 y usan Premium Storage.
RENDIMIENT
O MÁXIMO
DE
ALMACENA RENDIMIENT
MIENTO O MÁXIMO
Standard_D 1 3,5 7 4 4000 / 32 3200/48 2 / 750

S1_v2 (43)
RENDIMIENT
O MÁXIMO
DE
ALMACENA RENDIMIENT
MIENTO O MÁXIMO
Standard_D 2 7 14 8 8000 / 64 6400/96 2 / 1500

S2_v2 (86)
Standard_D 4 14 28 16 16000/128 12800/192 4 / 3000

S3_v2 (172)
Standard_D 8 28 56 32 32000/256 25600/384 8 / 6000

S4_v2 (344)
Standard_D 16 56 112 64 64000/512 51200/768 8 / 12 000

S5_v2 (688)
Serie Dv2
ACU: 210-250
Los tamaños de la serie DSv2 se ejecutan en procesadores Intel® Xeon® 8171M 2.1 GHz (Skylake), Intel®
Technology 2.0.
RENDIMIEN
TO MÁXIMO
DE
ALMACENA
MIENTO Nº MÁX. DE
GIB DE TEMPORAL: NIC/ANCHO
ALMACENA IOPS / MBPS DE BANDA
MIENTO DE LECTURA DISCOS DE DE RED
MEMORIA: TEMPORAL / MBPS DE DATOS RENDIMIENT ESPERADO
SIZE VCPU GIB (SSD) ESCRITURA MÁX. O: E/S (MBPS)
Standard_D 1 3,5 50 3000 / 46 / 4 4x500 2 / 750

1_v2 23
Standard_D 2 7 100 6000 / 93 / 8 8x500 2 / 1500

2_v2 46
Standard_D 4 14 200 12000 / 16 16x500 4 / 3000

3_v2 187 / 93
Standard_D 8 28 400 24000 / 32 32x500 8 / 6000

4_v2 375 / 187
Standard_D 16 56 800 48000 / 64 64x500 8 / 12 000

5_v2 750 / 375
Serie Av2
ACU: 100
Los tamaños de la serie Av2 se ejecutan en procesadores Intel® Xeon® 8171M 2.1 GHz (Skylake), Intel®
Technology 2.0 y usan Premium Storage.
RENDIMIENTO
MÁXIMO DE
ALMACENAMIE
NTO
ALMACENAMIE IOPS / MBPS DISCOS DE NIC/ANCHO DE
NTO DE LECTURA / DATOS MÁX. / BANDA DE RED
TEMPORAL MBPS DE RENDIMIENTO: ESPERADO
SIZE VCPU MEMORIA: GIB (SSD) ESCRITURA E/S (MBPS)
Standard_A1_ 1 2 10 1000 / 20 / 2 / 2x500 2 / 250

v2 10
Standard_A2_ 2 4 20 2000 / 40 / 4 / 4x500 2 / 500

v2 20
Standard_A4_ 4 8 40 4000 / 80 / 8 / 8x500 4 / 1000

v2 40
Standard_A8_ 8 16 80 8000 / 160 / 16 / 16x500 8 / 2000

v2 80
Standard_A2 2 16 20 2000 / 40 / 4 / 4x500 2 / 500

m_v2 20
Standard_A4 4 32 40 4000 / 80 / 8 / 8x500 4 / 1000

m_v2 40
Standard_A8 8 64 80 8000 / 160 / 16 / 16x500 8 / 2000

m_v2 80
Serie DC
RENDIMIENT
O MÁXIMO
DE
ALMACENA RENDIMIENT
MIENTO O MÁXIMO
Standard_D 2 8 100 2 4000 / 32 3200 /48 2 / 1500

C2s (43)
Standard_D 4 16 200 4 8000 / 64 6400 /96 2 / 3000

C4s (86)
Definiciones de tabla de tamaño

La capacidad de almacenamiento se muestra en unidades de GiB o 1024^3 bytes. Cuando compare discos
que se miden en GB (1000^3 bytes) con discos que se miden en GiB (1024^3), recuerde que los números
que representan la capacidad en GiB pueden parecer más pequeños. Por ejemplo, 1023 GiB = 1098.4 GB
Se midió el rendimiento de disco en operaciones de entrada/salida por segundo (E/S por segundo) y MBps,
donde Mbps = 10^6 bytes/s.
Los discos de datos pueden funcionar en modo en caché o en modo no en caché. En el caso de la operación
de disco de datos en caché, el modo de caché del host está establecido en ReadOnly o ReadWrite. En el caso
de la operación de disco de datos no en caché, el modo de caché del host está definido en None.
Si desea obtener el mejor rendimiento para las VM, debe limitar el número de discos de datos a 2 discos por
vCPU.
El ancho de banda de red esperado es el ancho de banda agregado máximo asignado por tipo de
máquina virtual en todas las NIC y para todos los destinos. Los límites superiores no están garantizados pero
están diseñados para proporcionar una guía a la hora de seleccionar el tipo correcto de máquina virtual para
la aplicación deseada. El rendimiento de red real dependerá de diversos factores (como, por ejemplo, la
congestión de la red, las cargas de la aplicación y la configuración de red). Para más información acerca de
cómo optimizar el rendimiento de red, consulte Optimización del rendimiento de red para Windows y Linux.
Para lograr el rendimiento de red esperado en Linux o Windows, puede que sea necesario seleccionar una
versión específica u optimizar la máquina virtual. Para más información, consulte Pruebas confiables para el
rendimiento de máquinas virtuales.
Otros tamaños
Proceso optimizado
Memoria optimizada
GPU optimizada
Pasos siguientes
Obtenga más información sobre cómo las unidades de proceso de Azure (ACU ) pueden ayudarlo a comparar el
rendimiento en los distintos SKU de Azure.
Tamaños de las máquinas virtuales ampliables serie B
La familia de máquinas virtuales de la serie B le permite elegir qué tamaño de máquina virtual proporciona el
rendimiento base necesario para su carga de trabajo, con la posibilidad de ampliar el rendimiento de la CPU hasta
el 100 % de una vCPU con procesador Intel® Broadwell E5-2673 v4 a 2.3 GHz o Intel® Haswell 2.4 GHz E5-2673
v3.
Las máquinas virtuales de la serie B son idóneas para cargas de trabajo que no necesitan un rendimiento completo
de la CPU de forma continua, como los servidores web, pruebas de concepto, pequeñas bases de datos y entornos
de desarrollo y de prueba. Estas cargas de trabajo suelen necesitar unos requisitos de rendimiento ampliables. La
serie B le brinda la posibilidad de adquirir un tamaño de máquina virtual con un rendimiento base al tiempo que la
instancia de máquina virtual acumula créditos si utiliza un rendimiento por debajo de este nivel de base. Cuando la
máquina virtual ha acumulado crédito se puede ampliar por encima de la base de referencia de esta con un uso de
hasta un 100 % de la vCPU si la aplicación necesita el mayor rendimiento de CPU posible.
La serie B incluye los siguientes tamaños de máquina virtual:
RENDI RENDI
MIEN MIEN
TO TO
MÁXI MÁXI
MO MO
REND DE DEL
REND IMIEN ALMA DISCO
IMIEN TO CENA SIN
GIB TO MÁXI MIEN ALMA
DE BASE MO TO CENA
ALMA DE DE CRÉDI TEMP MIEN
CENA CPU CPU CRÉDI TOS ORAL TO EN
MIEN DE LA DE LA TOS MÁXI DISC Y EN LA
TO MÁQ MÁQ CRÉDI INGR MOS OS DE CACH CACH
MEM TEMP UINA UINA TOS ESAD INGR DATO É: É: Nº
ORIA: ORAL VIRT VIRT INICI OS / ESAD S IOPS / IOPS / MÁX.
Stand 1 0,5 4 5% 100% 30 3 72 2 200/ 160/ 2

ard_B 10 10
1ls1
Stand 1 1 4 10% 100% 30 6 144 2 400 / 320 / 2

ard_B 10 10
1s
Stand 1 2 4 20% 100% 30 12 288 2 800 / 640 / 2

ard_B 10 10
1ms
Stand 2 4 8 40% 200% 60 24 576 4 1600 1280 3

ard_B / 15 / 15
2s
Stand 2 8 16 60% 200% 60 36 864 4 2400 1920 3

ard_B / 22.5 / 22.5
2ms
RENDI RENDI
MIEN MIEN
TO TO
MÁXI MÁXI
MO MO
REND DE DEL
REND IMIEN ALMA DISCO
IMIEN TO CENA SIN
GIB TO MÁXI MIEN ALMA
DE BASE MO TO CENA
ALMA DE DE CRÉDI TEMP MIEN
CENA CPU CPU CRÉDI TOS ORAL TO EN
MIEN DE LA DE LA TOS MÁXI DISC Y EN LA
TO MÁQ MÁQ CRÉDI INGR MOS OS DE CACH CACH
MEM TEMP UINA UINA TOS ESAD INGR DATO É: É: Nº
ORIA: ORAL VIRT VIRT INICI OS / ESAD S IOPS / IOPS / MÁX.
Stand 4 16 32 90% 400% 120 54 1296 8 3600 2880 4

ard_B / 35 / 35
4ms
Stand 8 32 64 135% 800% 240 81 1944 16 4320 4320 4

ard_B / 50 / 50
8ms
Stand 12 48 96 202 1200 360 121 2909 16 6480 4320 6

ard_B % % / 75 / 50
12ms
Stand 16 64 128 270 1600 480 162 3888 32 8640 4320 8

ard_B % % / 100 / 50
16ms
Stand 20 80 160 337 2000 600 203 4860 32 1080 4320 8

ard_B % % 0/ / 50
20ms 125
1 B1ls solo se admite en Linux
Ejemplo de carga de trabajo

Piense en una aplicación de registro de entrada y salida de una oficina. La aplicación necesita ráfagas de CPU
durante las horas laborales, pero no mucha capacidad de proceso durante horas de inactividad. En este ejemplo, la
carga de trabajo requiere una máquina virtual de 16vCPU con 64 GiB de RAM para trabajar de forma eficaz.
La tabla muestra los datos de tráfico por hora y el gráfico es una representación visual de ese tráfico.
Características de B16:
Rendimiento máximo de CPU: 16vCPU * 100 % = 1600 %
Línea de base: 270 %
CRÉDITOS
ESCENARIO HORA USO DE CPU (%) ACUMULADOS 1 CRÉDITOS DISPONIBLES
Implementación de Implementación Implementación 480 (créditos iniciales) 480

B16ms
Sin tráfico 0:00 0 162 642
Sin tráfico 1:00 0 162 804
Sin tráfico 2:00 0 162 966
Sin tráfico 3:00 0 162 1128
Sin tráfico 4:00 0 162 1290
Sin tráfico 5:00 0 162 1452
Poco tráfico 6:00 270 0 1452
Los empleados llegan 7:00 1280 -606 846

a la oficina (aplicación
necesita el 80 % de
vCPU)
Los empleados siguen 8:00 1280 -606 240

llegando a la oficina
(aplicación necesita el
80 % de vCPU)
Poco tráfico 9:00 270 0 240
Poco tráfico 10:00 100 102 342
Poco tráfico 11:00 50 132 474
Poco tráfico 12:00 100 102 576
Poco tráfico 13:00 100 102 678
Poco tráfico 14:00 50 132 810

CRÉDITOS
ESCENARIO HORA USO DE CPU (%) ACUMULADOS CRÉDITOS DISPONIBLES
Poco tráfico 15:00 100 102 912
Poco tráfico 16:00 100 102 1014
Los empleados 17:00 1600 -798 216

registran la salida (la
aplicación necesita el
100 % de vCPU)
Poco tráfico 18:00 270 0 216
Poco tráfico 19:00 270 0 216
Poco tráfico 20:00 50 132 348
Poco tráfico 21:00 50 132 480
Sin tráfico 22:00 0 162 642
Sin tráfico 23:00 0 162 804
1 Créditos acumulados y créditos utilizados en una hora son equivalente a:
((Base CPU perf of VM - CPU Usage) / 100) * 60 minutes .

Para un D16s_v3 que tiene 16 vCPU y 64 GiB de memoria, la tarifa por hora es de 0,936 USD por hora (673,92
USD al mes) y para B16ms con 16 vCPU y 64 GiB de memoria, la tarifa es de 0,794 USD por hora (547,86 USD al
mes). ¡Esto da como resultado un ahorro del 15 %!
Preguntas y respuestas
P: ¿Cómo obtener un 135 % del rendimiento base de una máquina virtual?
R. : Ese 135 % se debe compartir entre las 8 vCPU que componen el tamaño de la máquina virtual. Por ejemplo, si
la aplicación usa 4 de los 8 núcleos que están trabajando en el procesamiento por lotes y cada una de esas 4 vCPU
se ejecuta al 30 % de uso, la cantidad total de rendimiento de la CPU de la máquina virtual equivaldría al 120 %. Lo
que significa que la máquina virtual podría acumular créditos basándose en este 15% de diferencia con el
rendimiento base. Pero también significa que cuando tenga créditos disponibles, esa misma máquina virtual puede
utilizar el 100% de las 8 vCPU lo cual le proporcionaría a esa máquina virtual un rendimiento de CPU máximo del
800%.
P: ¿Cómo puedo supervisar mi saldo de crédito y consumo?
R. : Presentaremos 2 nuevas métricas en las próximas semanas, la métrica Credit le permitirá ver cuántos créditos
ha acumulado su máquina virtual y la métrica ConsumedCredit le mostrará cuántos créditos de la CPU ha
consumido la máquina virtual desde el banco. Podrá ver estas métricas desde el panel de métricas del portal o
mediante programación a través de las API de Azure Monitor.
Para más información acerca de cómo acceder a los datos de las métricas de Azure, consulte Información general
sobre las métricas en Microsoft Azure.
P: ¿Cómo se acumulan los créditos?
R. : Las tasas de acumulación y consumo de la máquina virtual se establecen de tal forma que una máquina virtual
que se esté ejecutando exactamente a su nivel de rendimiento base, no tendrá una acumulación ni un consumo
neto de créditos de ampliación. Una máquina virtual tendrá un aumento neto en el número de créditos siempre que
se esté ejecutando por debajo de su nivel de rendimiento base y tendrá una disminución neta cada vez que utilice
la CPU por encima de este nivel.
Ejemplo: Quiero implementar una máquina virtual con el tamaño B1ms para mi aplicación de base de datos a la
que se dedica poco tiempo y atención. Este tamaño permite que mi aplicación use hasta el 20 % de una vCPU
como base de referencia, lo cual significa 0,2 créditos por minuto que puedo usar o acumular.
Mi aplicación está ocupada al principio y al final de la jornada laboral de mis empleados, es decir, de 7:00 a 9:00
A.M. y de 4:00 a 6:00 PM. Durante las otras 20 horas del día, la aplicación suele estar inactiva y solo usa el 10% de
la vCPU. Durante las horas de poca actividad, gano 0,2 créditos por minuto y solo consumo 0,1 créditos por
minuto, por lo que la máquina virtual acumulará 0,1 x 60 = 6 créditos por hora. Es decir, durante las 20 horas de
poca actividad acumularé 120 créditos.
Durante las horas punta, la aplicación realiza un uso promedio del 60 % de la vCPU, sigo ganando 0,2 créditos por
minuto pero consumo 0,6 créditos por minuto, lo cual supone un costo neto de 0,4 créditos por minuto o 0,4 x 60
= 24 créditos por hora. Si tengo 4 horas al día de uso máximo, eso significa 4 x 24 = 96 créditos de consumo al día.
Si tomo los 120 créditos que acumulé durante las horas de poca actividad y le resto los 96 créditos que utilicé
durante las horas punta, obtendré 24 créditos adicionales que puedo acumular al día. Estos créditos los podré
utilizar en otras ampliaciones de actividades.
P: ¿Cómo puedo calcular los créditos acumulados y usados?
R. : Puede usar la siguiente fórmula:
(Rendimiento de CPU base de una máquina virtual - Uso de CPU ) / 100 = Créditos bancarios o uso por minuto
Por ejemplo, en la instancia anterior, su línea de base es del 20 % y si usa el 10 % de la CPU está acumulando (20 %
-10 %)/100 = 0,1 créditos por minuto.
P: ¿Admite la serie B discos de datos de Premium Storage?
R. : Sí, toda la serie B admite discos de datos de Premium Storage.
P: ¿Por qué tengo el crédito restante establecido en 0 después de volver a hacer una implementación o después
de una detención o inicio?
R : Si una máquina virtual se "REIMPLEMENTA" y se mueve a otro nodo, el crédito acumulado se pierde. En
cambio, si la máquina virtual se detiene y se inicia, pero sigue en el mismo nodo, conservará el crédito acumulado.
Cada vez que se inicia por primera vez una máquina virtual en un nodo, obtiene un crédito inicial. En el caso de
Standard_B8ms es de 240 minutos.
P: ¿Qué sucede si implemento una imagen de sistema operativo no admitida en B1ls?
R : B1ls solo admite imágenes de Linux y si implementa cualquier otra imagen de sistema operativo, podría no
obtener la mejor experiencia de cliente.
Otros tamaños
Uso general
Proceso optimizado
Memoria optimizada
GPU optimizada
Pasos siguientes
Tamaños de máquina virtual optimizada para
proceso
Los tamaños de máquina virtual optimizados para el proceso tiene un alto ratio entre CPU y memoria, y son
adecuados para servidores web de tráfico medios, aplicaciones de red, procesos por lotes y servidores de
aplicaciones. En este artículo, se proporciona información sobre el número de vCPU, discos de datos y NIC, así
como sobre el ancho de banda de red y almacenamiento para cada tamaño de esta agrupación.
La serie Fsv2 usa el procesador Intel® Xeon® Platinum 8168, que ofrece una velocidad de reloj Turbo
fundamental y sostenida de 3,4 GHz y una frecuencia turbo máxima de un solo núcleo de 3,7 GHz. Las
instrucciones de Intel® AVX-512, que son nuevas en los procesadores de Intel escalables, pueden llegar a
duplicar el rendimiento en las cargas de trabajo de procesamiento vectorial en las operaciones de número de
punto flotante de precisión individual y doble. En otras palabras, son muy rápidos para cualquier carga de
trabajo de cálculo.
Dado que su precio por hora es inferior, la serie Fsv2 tiene la mejor relación precio/rendimiento de la cartera de
Azure según la unidad de proceso de Azure (ACU ) por vCPU.
Serie Fsv2 1
ACU: 195 - 210
RENDIMIENT
O MÁXIMO
DE
ALMACENA RENDIMIENT
MIENTO O MÁXIMO
Standard_F 2 4 16 4 4000 / 31 3200 / 47 2 / 875

2s_v2 (32)
Standard_F 4 8 32 8 8000 / 63 6400 / 95 2/1750

4s_v2 (64)
Standard_F 8 16 64 16 16000 / 12800 / 4/3500

8s_v2 127 (128) 190
Standard_F 16 32 128 32 32000 / 25600 / 4/7000

16s_v2 255 (256) 380
Standard_F 32 64 256 32 64000 / 51200 / 8/14000

32s_v2 512 (512) 750
RENDIMIENT
O MÁXIMO
DE
ALMACENA RENDIMIENT
MIENTO O MÁXIMO
Standard_F 48 96 384 32 96000 / 76800 / 8 / 21000

48s_v2 768 (768) 1100
Standard_F 64 128 512 32 128000 / 80000 / 8/28000

64s_v2 1024 1100
(1024)
Standard_F 72 144 576 32 144000 / 80000 / 8 / 30 000

72s_v22, 3 1152 1100
(1520)
1Las máquinas virtuales de la serie Fsv2 cuentan con la tecnología Hyper-Threading de Intel®.
2 Si hay más de 64
vCPU, se necesita uno de estos sistemas operativos invitados compatibles: Windows Server
2016, Ubuntu 16.04 LTS, SLES 12 SP2 y Red Hat Enterprise Linux, CentOS 7.3 u Oracle Linux 7.3 con LIS 4.2.1
3 La instancia está aislada en el hardware dedicado a un solo cliente.

vCPU.
El ancho de banda de red esperado es el ancho de banda agregado máximo asignado por tipo de máquina
virtual en todas las NIC y para todos los destinos. Los límites superiores no están garantizados pero están
diseñados para proporcionar una guía a la hora de seleccionar el tipo correcto de máquina virtual para la
aplicación deseada. El rendimiento de red real dependerá de diversos factores (como, por ejemplo, la
Otros tamaños
Uso general
Memoria optimizada
GPU optimizada
Pasos siguientes
memoria
Los tamaños de VM optimizadas para memoria ofrecen una relación alta de memoria a CPU que es excelente
para servidores de bases de datos relacionales, memorias caché de medianas a grandes y análisis en memoria. En
este artículo, se proporciona información acerca del número de vCPU, discos de datos y tarjetas de interfaz de red,
así como del rendimiento del almacenamiento y del ancho de banda de red para cada tamaño de esta agrupación.
La serie Ev3 tiene el procesador Intel® Xeon® 8171M de 2,1 GHz (Skylake) o el procesador Intel® Xeon®
E5-2673 v4 de 2,3 GHz en una configuración de Hyper-Threading. Gracias a esto, proporciona una mejor
propuesta de valor para la mayoría de las cargas de trabajo de uso general y la equipara con las máquinas
virtuales de propósito general de la mayoría de las demás tecnologías de nube. Se ha ampliado la memoria
(de 7 GiB/vCPU a 8 GiB/vCPU ), y los límites de disco y red se han ajustado por núcleo para equipararse
con el cambio a hyperthreading. La serie Ev3 es la continuación de los tamaños de máquina virtual de
memoria alta de las familias D/Dv2.
Las series Eav4 y Easv4 utilizan el procesador EPYC TM 7452 de 2,35 GHz de AMD en una configuración de
varios subprocesos con una caché L3 de hasta 256 MB, lo que aumenta las opciones para ejecutar la
mayoría de las cargas de trabajo optimizadas para memoria. Las series Eav4 y Easv4 tienen las mismas
configuraciones de memoria y disco que las series Ev3 y Esv3.
La serie Mv2 ofrece el mayor número de vCPU (hasta 416 vCPU ) y la memoria más grande (hasta
8,19 TiB ) de todas las máquinas virtuales en la nube. Es ideal para bases de datos extremadamente grandes
u otras aplicaciones que se benefician de un elevado número de vCPU y grandes cantidades de memoria.
La serie M ofrece un elevado recuento de vCPU (hasta 128 vCPU ) y una gran cantidad de memoria (hasta
3,8 TiB ). También es ideal para bases de datos extremadamente grandes u otras aplicaciones que se
benefician de un elevado número de vCPU y grandes cantidades de memoria.
Las series Dv2, G y DSv2/GS son ideales para las aplicaciones que requieren vCPU más rápidas, mejor
rendimiento del almacenamiento temporal o tienen mayor demanda de memoria. Ofrecen una
combinación eficaz para muchas aplicaciones de clase empresarial.
Serie de Dv2, una evolución de la serie D original, presenta una CPU más eficaz. La serie Dv2 es un 35 %
aproximadamente más rápida que la serie D. Se ejecuta en procesadores Intel® Xeon® 8171M de 2,1 GHz
(Skylake), Intel® Xeon® E5-2673 v4 de 2,3 GHz (Broadwell) o Intel® Xeon® E5-2673 v3 de 2,4 GHz
(Haswell) y con la tecnología Intel Turbo Boost Technology 2.0. La serie Dv2 tiene las mismas
configuraciones de disco y memoria que la serie D.
Azure Compute ofrece tamaños de máquinas virtuales que están aislados para un tipo concreto de
hardware y dedicados a un solo cliente. Estos tamaños de máquina virtual son más adecuados para cargas
de trabajo que requieren un alto grado de aislamiento de otros clientes como, por ejemplo, las cargas de
trabajo que incluyen elementos como el cumplimiento normativo y los requisitos legales. Los clientes
también puede elegir subdividir aún más los recursos de estas máquinas virtuales aisladas mediante la
compatibilidad de Azure para máquinas virtuales anidadas. Consulte las tablas de familias de máquinas
virtuales que aparecen a continuación para ver las opciones de las máquinas virtuales aisladas.
Serie Esv3
ACU: 160-190 1
La serie Ev3 tiene el procesador Intel® Xeon® 8171M de 2,1 GHz (Skylake) o el procesador Intel® Xeon® E5-
2673 v4 de 2,3 GHz (Broadwell), puede alcanzar 3,5 GHz con la tecnología Intel Turbo Boost Technology 2.0 y usa
almacenamiento prémium. Las instancias de la serie Ev3 son ideales para aplicaciones empresariales de uso
intensivo de memoria.
RENDIMIENT
O MÁXIMO
DE
ALMACENAM RENDIMIENT
IENTO O MÁXIMO
ALMACENAM IOPS / MBPS ALMACENAM DE BANDA
IENTO (TAMAÑO DE IENTO EN LA DE RED
MEMORIA: TEMPORAL DISCOS DE CACHÉ EN CACHÉ: IOPS ESPERADO
SIZE VCPU GIB (SSD) DATOS MÁX. GIB) / MBPS (MBPS)
Standard_E 2 16 32 4 4000/32 3200/48 2 / 1000

2s_v3 (50)
Standard_E 4 32 64 8 8000/64 6400/96 2 / 2000

4s_v3 2 (100)
Standard_E 8 64 128 16 16000/128 12800/192 4/4000

8s_v3 2 (200)
Standard_E 16 128 256 32 32000/256 25600/384 8 / 8000

16s_v3 2 (400)
Standard_E 20 160 320 32 40000 / 32000 / 8 / 10 000

20s_v3 320 (400) 480
Standard_E 32 256 512 32 64000/512 51200/768 8 / 16000

32s_v3 2 (800)
Standard_E 48 384 768 32 96000/768 76800 / 8 / 24000

48s_v3 2 (1200) 1152
Standard_E 64 432 864 32 128000/10 80000/120 8 / 30 000

64s_v3 2 24 (1600) 0
Standard_E 64 432 864 32 128000/10 80000/120 8 / 30 000

64is_v3 3 24 (1600) 0
1 Las máquinas virtuales de la serie Esv3 cuentan con la tecnología Hyper-Threading de Intel®.
2 Tamaños de núcleos restringidos disponibles.
Serie Easv4
ACU: 230 - 260
TM
Los tamaños de la serie Easv4 se basan en el procesador EPYC TM 7452 de AMD de 2,35 Ghz que pueden alcanzar
una frecuencia máxima incrementada de 3,35 Ghz y usar SSD Premium. Los tamaños de la serie Easv4 son
ideales para aplicaciones empresariales de uso intensivo de memoria.
RENDIMIENT
O MÁXIMO
DE
IENTO O MÁXIMO
Standard_E 2 16 32 4 4000/32 3200/48 2 / 1000

2as_v4 (50)
Standard_E 4 32 64 8 8000/64 6400/96 2 / 2000

4as_v4 (100)
Standard_E 8 64 128 16 16000/128 12800/192 4/4000

8as_v4 (200)
Standard_E 16 128 256 32 32 000 / 25600/384 8 / 8000

16as_v4 255 (400)
Standard_E 20 160 320 32 40000 / 32000 / 8 / 10 000

20as_v4 320 (500) 480
Standard_E 32 256 512 32 64 000 / 51200/768 8 / 16000

32as_v4 510 (800)
Standard_E 48 384 768 32

48as_v4 **
Standard_E 64 512 1024 32

64as_v4 **
Standard_E 96 672 1344 32

96as_v4 **
Serie Ev3
ACU: 160 - 190 1
La serie Ev3 tiene el procesador Intel® Xeon® 8171M de 2,1 GHz (Skylake) o el procesador Intel® Xeon® E5-
2673 v4 de 2,3 GHz (Broadwell) y puede alcanzar 3,5 GHz con la tecnología Intel Turbo Boost Technology 2.0. Las
instancias de la serie Ev3 son ideales para aplicaciones empresariales de uso intensivo de memoria.
El almacenamiento en disco de datos se factura de forma independiente a las máquinas virtuales. Para usar discos
de Premium Storage, utilice los tamaños ESv3. Los precios y los medidores de facturación para los tamaños ESv3
son los mismos que para la serie Ev3.
RENDIMIENTO
MÁXIMO DE
ALMACENAMIE
NTO
GIB DE TEMPORAL:
ALMACENAMIE IOPS / MBPS DE
NTO LECTURA / ANCHO DE
TEMPORAL DISCOS DE MBPS DE BANDA DE
SIZE VCPU MEMORIA: GIB (SSD) DATOS MÁX. ESCRITURA RED/NIC MÁX.
Standard_E2_ 2 16 50 4 3000/46/23 2 / 1000

v3
Standard_E4_ 4 32 100 8 6000/93/46 2 / 2000

v3
Standard_E8_ 8 64 200 16 12000/187/9 4/4000

v3 3
Standard_E16 16 128 400 32 24000/375/1 8 / 8000

_v3 87
Standard_E20 20 160 500 32 30000/469/2 8 / 10 000

_v3 34
Standard_E32 32 256 800 32 48000/750/3 8 / 16000

_v3 75
Standard_E48 48 384 1200 32 96000/1000/ 8 / 24000

_v3 500
Standard_E64 64 432 1600 32 96000/1000/ 8 / 30 000

_v3 500
Standard_E64i 64 432 1600 32 96000/1000/ 8 / 30 000

_v3 2, 3 500
1 Las máquinas virtuales de la serie Ev3 cuentan con la tecnología Hyper-Threading de Intel®.
Serie Eav4
ACU: 230 - 260
Los tamaños de la serie Eav4 se basan en el procesador EPYC TM 7452 de AMD de 2,35 Ghz que pueden alcanzar
una frecuencia máxima incrementada de 3,35 Ghz y usar SSD Premium. Los tamaños de la serie Eav4 son ideales
para aplicaciones empresariales de uso intensivo de memoria. El almacenamiento en disco de datos se factura de
forma independiente a las máquinas virtuales. Para usar SSD Premium, use los tamaños de la serie Easv4. El
precio y los medidores de facturación para los tamaños Easv4 son los mismos que para la serie Eav3.
RENDIMIENTO
MÁXIMO DE
ALMACENAMIE
NTO
GIB DE TEMPORAL: Nº MÁX. DE NIC
ALMACENAMIE IOPS / MBPS DE / ANCHO DE
NTO LECTURA / BANDA DE RED
TEMPORAL DISCOS DE MBPS DE ESPERADO
Standard_E2a 2 16 50 4 3000 / 46 / 2 / 1000

_v4 23
Standard_E4a 4 32 100 8 6000 / 93 / 2 / 2000

_v4 46
Standard_E8a 8 64 200 16 12000 / 187 / 4/4000

_v4 93
Standard_E16 16 128 400 32 24000 / 375 / 8 / 8000

a_v4 187
Standard_E20 20 160 500 32 30000 / 468 / 8 / 10 000

a_v4 234
Standard_E32 32 256 800 32 48000 / 750 / 8 / 16000

a_v4 375
Standard_E48 48 384 1200 32

a_v4 **
Standard_E64 64 512 1600 32

a_v4 **
Standard_E96 96 672 2400 32

a_v4 **
Serie Mv2
ACU: 188-2801
Acelerador de escritura: Compatible
La serie Mv2 ofrece una plataforma de alto rendimiento y baja latencia que se ejecuta en un procesador Intel®
Xeon® Platinum 8180M de 2,5 GHz (Skylake) con tecnología Hyper-Threading con una frecuencia básica de
2,5 GHz y una frecuencia turbo máxima de 3,8 GHz. Todos los tamaños de máquina virtual de la serie Mv2
pueden usar discos persistentes estándar y premium. Las instancias de la serie Mv2 son tamaños de máquinas
virtuales optimizados para memoria que proporcionan un rendimiento de proceso sin precedentes para admitir
grandes bases de datos y cargas de trabajo en memoria, con una relación elevada de memoria y CPU que es
perfecta para servidores de bases de datos relacionales, grandes almacenamientos en caché y análisis en
memoria.
RENDIMIENT
O MÁXIMO
DE
IENTO O MÁXIMO
Standard_M 208 5700 4096 64 80000/800 40000/100 8 / 16000

208ms_v22 (7040) 0
Standard_M 208 2850 4096 64 80000/800 40000/100 8 / 16000

208s_v22 (7040) 0
Standard_M 416 11 400 8192 64 250 000 / 80000 / 8 / 32 000

416ms_v22, 1600 2000
3 (14 080)
Standard_M 416 5700 8192 64 250 000 / 80000 / 8 / 32 000

416s_v22, 3 1600 2000
(14 080)
1 Las máquinas virtuales de la serie Mv2 cuentan con la tecnología Hyper-Threading de Intel®
2 Las máquinas virtuales de la serie Mv2son solo de la segunda generación. Si usa Linux, consulte Compatibilidad
para máquinas virtuales de generación 2 en Azure para obtener instrucciones sobre cómo buscar y seleccionar
una imagen.
3 Para los tamaños
M416ms_v2 y M416s_v2, tenga en cuenta que inicialmente solo se admite la siguiente imagen:
"GEN2: SUSE Linux Enterprise Server (SLES ) 12 SP4 para SAP Applications".
Serie M
ACU: 160-180 1
Los tamaños de la serie M se basan en la CPU Intel(R ) Xeon(R ) E7-8890 v3 @ 2,50 GHz
Acelerador de escritura: Compatible
RENDIMIENT
O MÁXIMO
DE
IENTO O MÁXIMO
Standard_M 8 218,75 256 8 10000 / 5000 / 125 4 / 2000

8ms 3 100 (793)
RENDIMIENT
O MÁXIMO
DE
IENTO O MÁXIMO
Standard_M 16 437,5 512 16 20000/200 10000/250 8 / 4000

16ms 3 (1587)
Standard_M 32 192 1024 32 40000/400 20000/500 8 / 8000

32ts (3174)
Standard_M 32 256 1024 32 40000/400 20000/500 8 / 8000

32ls (3174)
Standard_M 32 875 1024 32 40000/400 20000/500 8 / 8000

32ms 3 (3174)
Standard_M 64 1024 2048 64 80000/800 40000/100 8 / 16000

64s (6348) 0
Standard_M 64 512 2048 64 80000/800 40000/100 8 / 16000

64ls (6348) 0
Standard_M 64 1792 2048 64 80000/800 40000/100 8 / 16000

64ms 3 (6348) 0
Standard_M 128 2048 4096 64 160000 / 80000 / 8 / 30 000

128s 2 1600 2000
(12696)
Standard_M 128 3892 4096 64 160000 / 80000 / 8 / 30 000

128ms 2, 3, 1600 2000
4 (12696)
Standard_M 64 1024 7168 64 80000 / 40000/100 8 / 16000

64 800 (1228) 0
Standard_M 64 1792 7168 64 80000 / 40000/100 8 / 16000

64m 800 (1228) 0
Standard_M 128 2048 14336 64 250000 / 80000 / 8 / 32 000

128 2 1600 2000
(2456)
Standard_M 128 3892 14336 64 250000 / 80000 / 8 / 32 000

128m 2 1600 2000
(2456)
1 Las VM de la serie M cuentan con la tecnología Hyper-Threading de Intel®

2 Más de 64vCPU requieren uno de estos sistemas operativos invitados compatibles: Windows Server 2016,
Ubuntu 16.04 LTS, SLES 12 SP2 y Red Hat Enterprise Linux, CentOS 7.3 u Oracle Linux 7.3 con LIS 4.2.1.
3
DSv2-series 11-15
ACU: 210 - 250 1
Los tamaños de la serie DSv2 se ejecutan en procesadores Intel® Xeon® 8171M de 2,1 GHz (Skylake), Intel®
Xeon® E5-2673 v4 de 2,3 GHz (Broadwell) o Intel® Xeon® E5-2673 v3 de 2,4 GHz (Haswell).
RENDIMIENT
O MÁXIMO
DE
IENTO O MÁXIMO
Standard_D 2 14 28 8 8000 / 64 6400/96 2 / 1500

S11_v2 3 (72)
Standard_D 4 28 56 16 16000 / 12800/192 4 / 3000

S12_v2 3 128 (144)
Standard_D 8 56 112 32 32000 / 25600/384 8 / 6000

S13_v2 3 256 (288)
Standard_D 16 112 224 64 64000 / 51200/768 8 / 12 000

S14_v2 3 512 (576)
Standard_D 20 140 280 64 80000 / 64000 / 8 / 25

S15_v2 2 640 (720) 960 000 4
1 El rendimiento de disco máx. ( E/S por segundo o Mbps) posible con una VM de la serie DSv2 puede estar
limitado por el número, el tamaño y la fragmentación de los discos conectados. Para información detallada,
consulte Azure Premium Storage: Diseño de alto rendimiento.
4 25 000 Mbps con redes aceleradas.
Dv2-series 11-15
ACU: 210 - 250
Los tamaños de la serie DSv2 se ejecutan en procesadores Intel® Xeon® 8171M de 2,1 GHz (Skylake), Intel®
Xeon® E5-2673 v4 de 2,3 GHz (Broadwell) o Intel® Xeon® E5-2673 v3 de 2,4 GHz (Haswell).
RENDIMIENTO
MÁXIMO DE
ALMACENAMIE
NTO
ALMACENAMIE IOPS / MBPS DE DISCOS DE NIC/ANCHO DE
NTO LECTURA / DATOS MÁX. / BANDA DE RED
Standard_D11 2 14 100 6000 / 93 / 8 / 8x500 2 / 1500

_v2 46
Standard_D12 4 28 200 12000 / 187 / 16 / 16x500 4 / 3000

_v2 93
Standard_D13 8 56 400 24000 / 375 / 32 / 32x500 8 / 6000

_v2 187
Standard_D14 16 112 800 48000 / 750 / 64 / 64x500 8 / 12 000

_v2 375
Standard_D15 20 140 1000 60000 / 937 / 64 / 64x500 8 / 25 000 2

_v2 1 468

2 25 000 Mbps con redes aceleradas.

La capacidad de almacenamiento se muestra en unidades de GiB o 1024^3 bytes. Cuando compare discos que
se miden en GB (1000^3 bytes) con discos que se miden en GiB (1024^3), recuerde que los números que
representan la capacidad en GiB pueden parecer más pequeños. Por ejemplo, 1023 GiB = 1098.4 GB
Los discos de datos pueden funcionar en modo en caché o en modo no en caché. En el caso de la operación de
disco de datos en caché, el modo de caché del host está establecido en ReadOnly o ReadWrite. En el caso de
la operación de disco de datos no en caché, el modo de caché del host está definido en None.
vCPU.
Otros tamaños
Uso general
Proceso optimizado
GPU optimizada
Pasos siguientes
Tamaños de VM que admiten vCPU restringidas
Algunas cargas de trabajo de base de datos como SQL Server u Oracle requieren mucha memoria,
almacenamiento y ancho de banda de E/S, pero no un recuento de núcleos alto. Muchas cargas de trabajo de base
de datos no consumen demasiados recursos de CPU. Azure ofrece determinados tamaños de VM que permiten
restringir el recuento de vCPU de VM para reducir el costo de licencias de software y mantener la misma memoria,
almacenamiento y ancho de banda de E/S.
Se puede restringir el número de vCPU a la mitad o un cuarto del tamaño de VM original. Estos nuevos tamaños
de VM tienen un sufijo que especifica el número de vCPU activas para facilitar su identificación.
Por ejemplo, el tamaño de VM Standard_GS5 actual incluye 32 vCPU, 448 GB de RAM, 64 discos (hasta 256 TB ) y
80 000 E/S por segundo o 2 GB/s de ancho de banda de E/S. Los nuevos tamaños de VM Standard_GS5-16 y
Standard_GS5-8 incluyen 16 y 8 vCPU activas, respectivamente y mantienen el resto de especificaciones de
Standard_GS5 para memoria, almacenamiento y ancho de banda de E/S.
Las tarifas de licencias que se cobran para SQL Server u Oracle están restringidas al nuevo recuento de vCPU y
otros productos deben cobrarse según el nuevo recuento de vCPU. Esto provoca un aumento de entre el 50 % y el
75 % de la relación de las especificaciones de VM con vCPU activas (facturables). Estos nuevos tamaños de
máquina virtual permiten que las cargas de trabajo de los clientes usen la misma memoria, almacenamiento y
ancho de banda de entrada y salida, al tiempo que se optimiza el costo que generan por las licencias de software.
En este momento, el costo de proceso, que incluye licencias de sistema operativo, es igual que el del tamaño
original. Para más información, consulte Azure VM sizes for more cost-effective database workloads (Tamaños de
VM de Azure para cargas de trabajo de base de datos más rentables).
NOMBRE VCPU ESPECIFICACIONES
Standard_M8-2ms 2 Igual que M8ms
Standard_E4-2s_v3 2 Igual que E4s_v3

NOMBRE VCPU ESPECIFICACIONES
Standard_GS4-8 8 Igual que GS4
Standard_DS11-1_v2 1 Igual que DS11_v2
Otros tamaños
Proceso optimizado
Memoria optimizada
GPU
Pasos siguientes
almacenamiento
Los tamaños de VM optimizadas para almacenamiento proporcionan un alto rendimiento de disco y de E/S y son
ideales para macrodatos, bases de datos SQL y NoSQL, almacenamiento de datos y bases de datos
transaccionales grandes. Por ejemplo, Cassandra, MongoDB, Cloudera y Redis. En este artículo, se proporciona
información acerca del número de vCPU, discos de datos y tarjetas de interfaz de red, así como del rendimiento
del almacenamiento local y del ancho de banda de red para cada tamaño optimizado.
La serie Lsv2 proporciona un alto rendimiento, baja latencia, almacenamiento NVMe local asignado directamente
que se ejecuta en el procesador AMD EPYC ™ 7551 con una potencia en todos los núcleos de 2,55 GHz y una
potencia máxima de 3,0 GHz. Las máquinas virtuales de la serie Lsv2 están disponibles en tamaños de 8 a 80
vCPU en una configuración de varios subprocesos simultáneos. Hay 8 GiB de memoria por vCPU y un dispositivo
SSD NVMe M.2 de 1,92 TB por cada 8 vCPU, con hasta 19,2 TB (10 x 1,92 TB ) disponibles en la versión L80s v2.
NOTE
Las máquinas virtuales de la serie Lsv2 están optimizadas para usar el disco local del nodo conectado directamente a la
máquina virtual, en lugar de utilizar discos de datos duraderos. Esto permite mayores IOPS por rendimiento para las cargas
de trabajo. Las series Lsv2 y Ls no admiten la creación de una memoria caché local para aumentar el número de E/S por
segundo que pueden alcanzar los discos de datos duraderos.
El alto rendimiento y el elevado número de E/S por segundo del disco local hace de que las máquinas virtuales de las series
Lsv2 y Ls sean ideales para almacenes NoSQL, como Apache Cassandra y MongoDB, que replican datos en diferentes
máquinas virtuales para lograr la persistencia en caso de error de una máquina virtual individual.
Para más información, consulte Optimización del rendimiento en las máquinas virtuales de la serie Lsv2.
Serie Lsv2
ACU: 150-175
RENDIMIE
NTO MÁX. Nº MÁX.
RENDIMIE DE DISCO DE
NTO DE DE DATOS NIC/ANCH
DISCO NO EN O DE
NVME3 CACHÉ (E/S BANDA DE
DISCO (IOPS DE POR Nº MÁX. RED
MEMORIA TEMPORAL DISCOS LECTURA/ SEGUNDO DE DISCOS ESPERADO
SIZE VCPU (GIB) 1 (GIB) NVME2 MBPS) /MBPS)4 DE DATOS (MBPS)
Standard_ 8 64 80 1 de 1,92 400 000/ 8000/160 16 2/3200

L8s_v2 TB 2000
Standard_ 16 128 160 2 de 1,92 800 000/ 16 000/3 32 4/6400

L16s_v2 TB 4000 20
RENDIMIE
NTO MÁX. Nº MÁX.
RENDIMIE DE DISCO DE
NTO DE DE DATOS NIC/ANCH
DISCO NO EN O DE
NVME CACHÉ (E/S BANDA DE
DISCO (IOPS DE POR Nº MÁX. RED
MEMORIA TEMPORAL DISCOS LECTURA/ SEGUNDO DE DISCOS ESPERADO
SIZE VCPU (GIB) (GIB) NVME MBPS) /MBPS) DE DATOS (MBPS)
Standard_ 32 256 320 4 de 1,92 1,5 32 000/6 32 8/12 800

L32s_v2 TB mill./8000 40
Standard_ 48 384 480 6x1.92 TB 2.2M / 48000/96 32 8/más de

L48s_v2 14000 0 16 000
Standard_ 64 512 640 8 de 1,92 2,9 64 000/1 32 8/más de

L64s_v2 TB mill./1600 280 16 000
0
Standard_ 80 640 800 10 de 3,8 mill./2 80 000/1 32 8/más de

L80s_v25 1,92 TB 0 000 400 16 000
1 Las máquinas virtuales de la serie Lsv2tienen un disco de recursos temporal basado en el estándar SCSI para
paginación o el archivo de intercambio del sistema operativo (D: en Windows, /dev/sdb en Linux). Dicho disco
proporciona 80 GiB de almacenamiento, 4000 IOPS y una velocidad de transferencia de 80 MBps por cada 8
vCPU (p. ej., el tamaño Standard_L80s_v2 proporciona 800 GiB a 40 000 IOPS y 800 MBps). Esto garantiza que
las unidades de NVMe se puedan dedicar completamente al uso de aplicaciones. Este disco es efímero y se
perderán todos los datos al detenerlo o desasignarlo.
2 Los discos NVMe locales son efímeros y los datos se perderán en estos discos si se detiene o desasigna la VM.
3 La tecnología Hyper -V NVMe Direct proporciona acceso sin límite a las unidades de NVMe locales asignadas
de forma segura al espacio de VM de invitado. Para lograr el máximo rendimiento es necesario usar la última
compilación WS2019 o Ubuntu 18.04 o 16.04 de Azure Marketplace. El rendimiento de escritura varía en función
del tamaño de E/S, la carga de unidad y la utilización de capacidad.
4 LasVM de la serie Lsv2 no proporcionan almacenamiento caché de host para el disco de datos, ya que las
cargas de trabajo de Lsv2 no se ven beneficiadas. Sin embargo, las máquinas virtuales Lsv2 pueden admitir la
opción de disco de sistema operativo efímero de máquina virtual de Azure (hasta 30 GiB ).
5 las máquinas virtuales con más de 64 vCPU requieren uno de estos sistemas operativos invitados compatibles:
Windows Server 2016 o posterior
Ubuntu 16.04 LTS o posterior, con kernel ajustado para Azure (kernel 4.15 o posterior)
SLES 12 SP2 o posterior
RHEL o CentOS, versiones 6.7 a 6.10, con la versión 4.3.1 (o posterior) del paquete LIS proporcionado por
Microsoft instalada
RHEL o CentOS, versión 7.3, con la versión 4.2.1 (o posterior) del paquete LIS proporcionado por Microsoft
instalada
RHEL o CentOS, versión 7.6 o posterior
Oracle Linux con UEK4 o posterior
Debian 9 con el kernel de backports, Debian 10 o posterior
CoreOS con un kernel 4.14 o posterior

que se miden en GB (1000^3 bytes) con discos que se miden en GiB (1024^3), recuerde que los números que
representan la capacidad en GiB pueden parecer más pequeños. Por ejemplo, 1023 GiB = 1098.4 GB
vCPU.
Otros tamaños
Uso general
Proceso optimizado
Memoria optimizada
GPU optimizada
Pasos siguientes
Aprenda a Optimizar el rendimiento en las máquinas virtuales de la serie Lsv2.
Optimización del rendimiento en las máquinas
virtuales de la serie Lsv2
Las máquinas virtuales de la serie Lsv2 admiten una variedad de cargas de trabajo que necesitan una elevada
cantidad de E/S y rendimiento en el almacenamiento local en una amplia gama de sectores y aplicaciones. La
serie Lsv2 es ideal para macrodatos, SQL, bases de datos NoSQL, almacenamiento de datos y bases de datos
transaccionales de gran tamaño, como Cassandra, MongoDB, Cloudera y Redis.
El diseño de las máquinas virtuales de la serie Lsv2 maximiza el procesador AMD EPYC™ 7551 para proporcionar
el mejor rendimiento entre el procesador, la memoria, las máquinas virtuales y los dispositivos NVMe. Además de
maximizar el rendimiento del hardware, las máquinas virtuales de la serie Lsv2 están diseñadas para responder a
las necesidades de los sistemas operativos Windows y Linux para mejorar el rendimiento con el hardware y el
software.
El ajuste del hardware y el software dio lugar a la versión optimizada de Windows Server 2019 Datacenter, que se
publicó a principios de diciembre de 2018 en Azure Marketplace, que admite el rendimiento máximo en los
dispositivos NVMe en las máquinas virtuales de la serie Lsv2.
En este artículo se proporcionan consejos y sugerencias para asegurarse de que las cargas de trabajo y las
aplicaciones alcanzan el máximo rendimiento diseñado en las máquinas virtuales. La información de esta página
se actualizará continuamente a medida que se agreguen más imágenes optimizadas de Lsv2 a Azure Marketplace.
Arquitectura del conjunto de chips AMD EYPC™

Las máquinas virtuales de la serie Lsv2 usan procesadores de servidor AMD EYPC™ basados en la
microarquitectura Zen. AMD desarrolló Infinity Fabric (IF ) para EYPC™ como interconexión escalable para su
modelo NUMA que podría usarse para las comunicaciones en la placa, en el paquete y en comunicaciones de
varios paquetes. En comparación con QPI (Quick-Path Interconnect) y UPI (Ultra-Path Interconnect), que se usan
en los procesadores de placa monolítica moderna de Intel, la arquitectura de muchas placas pequeñas de NUMA
de AMD aporta beneficios de rendimiento, por un lado, y diferentes retos por el otro. La repercusión real de las
restricciones de ancho de banda y latencia de memoria puede variar según el tipo de cargas de trabajo.
Sugerencias para maximizar el rendimiento

El hardware de las máquinas virtuales de la serie Lsv2 utiliza dispositivos NVMe con ocho pares de cola de
E/S. Cada cola de E/S de dispositivo NVMe es realmente un par: una cola de envío y una cola de
finalización. El controlador de NVMe está configurado para optimizar el uso de estos ocho pares de cola de
E/S distribuyendo la E/S en una programación de round robin. Para obtener un rendimiento máximo,
ejecute ocho trabajos por dispositivo para hacerlos coincidir.
Evite mezclar los comandos de administrador de NVMe (por ejemplo, la consulta de información SMART
de NVMe, etc.) con comandos de E/S de NVMe durante las cargas de trabajo activas. Los dispositivos
NVMe de la serie Lsv2 están respaldados por la tecnología NVMe Direct de Hyper-V, que se activa en
"modo de baja velocidad" cada vez que haya comandos de administrador de NVMe pendientes. Los
usuarios de la serie Lsv2 podrían experimentar una importante caída en el rendimiento de E/S de NVMe si
esto sucede.
Los usuarios de Lsv2 no deben depender de la información de NUMA del dispositivo (todo 0) que se
notifica en la máquina virtual para las unidades de datos para decidir la afinidad de NUMA para sus
aplicaciones. La manera recomendada de mejorar el rendimiento es distribuir las cargas de trabajo entre las
CPU, si es posible.
La profundidad máxima de cola admitida por cada par de cola de E/S para un dispositivo NVMe de una
máquina virtual de la serie Lsv2 es 1024 (frente al límite de profundidad de cola de 32 de Amazon i3). Los
usuarios de Lsv2 deben limitar sus cargas de trabajo de pruebas comparativas (sintéticas) a la profundidad
de cola de 1024 o inferior para evitar que se desencadenen condiciones de cola completa, que pueden
reducir el rendimiento.
Uso de almacenamiento local de NVMe

El almacenamiento local en el disco de NVMe de 1,92 TB de todas las máquinas virtuales de Lsv2 es efímero.
Durante un reinicio estándar correcto de la máquina virtual, se conservarán los datos del disco local de NVMe. No
se conservarán los datos en el NVMe si la máquina virtual se vuelve a implementar, se desasigna o se elimina. No
se conservarán los datos si algún otro problema provoca un error en el estado de la máquina virtual o el hardware
en que se está ejecutando. Cuando esto sucede, se borran de forma segura los datos en el host antiguo.
También habrá casos en que la máquina virtual debe moverse a una máquina de un host diferente; por ejemplo,
durante una operación de mantenimiento planeado. Las operaciones de mantenimiento planeado y algunos
errores de hardware pueden anticiparse con los eventos programados. Scheduled Events debe usarse para
mantenerse actualizado en todas las operaciones de recuperación y mantenimiento previstas.
En el caso de que un evento de mantenimiento planeado requiera que la máquina virtual se vuelva a crear en un
nuevo host con discos locales vacíos, los datos se deben volver a sincronizar (de nuevo, borrando de forma segura
los datos del host antiguo). Esto ocurre porque las máquinas virtuales de la serie Lsv2 no admiten actualmente la
migración en vivo en el disco local de NVMe.
Existen dos modos de realizar el mantenimiento planeado.
Mantenimiento controlado por el cliente de máquina virtual estándar
La máquina virtual se mueve a un host actualizado durante un período de 30 días.
Los datos del almacenamiento local de Lsv2 podrían perderse, por lo que se recomienda realizar copias de
seguridad datos antes del evento.
Mantenimiento automático
Se produce si el cliente no ejecuta el mantenimiento controlado por el cliente o en caso de procedimientos de
emergencias, como un evento de seguridad de día cero.
Diseñado para conservar los datos del cliente, pero hay un pequeño riesgo de bloqueo o reinicio de la máquina
virtual.
Los datos del almacenamiento local de Lsv2 podrían perderse, por lo que se recomienda realizar copias de
seguridad datos antes del evento.
Para los próximos eventos de servicio, utilice el proceso de mantenimiento controlado para seleccionar un
momento más conveniente para la actualización. Antes del evento, puede realizar una copia de seguridad de los
datos en almacenamiento premium. Una vez completado el evento de mantenimiento, puede devolver los datos al
almacenamiento de NVMe local de las máquinas virtuales Lsv2 actualizadas.
Entre los escenarios que mantienen los datos en discos NVMe locales están los siguientes:
La máquina virtual se está ejecutando y se encuentra en buen estado.
La máquina virtual se reinicia in situ (por usted o Azure).
La máquina virtual se pausa (detenida sin desasignación).
La mayoría de las operaciones de servicio del mantenimiento planeado.
Los escenarios que borran de forma segura los datos para proteger al cliente incluyen:
La máquina virtual se vuelve a implementar, se detiene (desasigna) o se elimina (por usted).
La máquina virtual pasa a un estado incorrecto y es necesario recurrir a otro nodo debido a un problema de
hardware.
Un pequeño número de las operaciones de servicio de mantenimiento planeado que requiere que la VM se
reasigne a otro host para el servicio.
Para más información acerca de las opciones de la copia de seguridad de datos en el almacenamiento local,
consulte Copia de seguridad y recuperación ante desastres para discos IaaS de Azure.

¿Cómo se puede iniciar la implementación de máquinas virtuales de la serie Lsv2?
Al igual que cualquier otra máquina virtual, use el Portal, la CLI de Azure o PowerShell para crear una
máquina virtual.
¿Un único error de disco NVMe provocará un error en todas las máquinas virtuales del host?
Si se detecta un error de disco en el nodo de hardware, el hardware está en estado de error. Cuando esto
ocurre, se anula la asignación de todas las máquinas virtuales del nodo y estas se mueven a un nodo en
buen estado. En el caso de las máquinas virtuales de la serie Lsv2, esto significa que los datos del cliente en
el nodo con error se borran de forma segura y el cliente tendrá que volver a crearlos en el nuevo nodo.
Como se indicó, antes de que la migración en vivo esté disponible en Lsv2, los datos del nodo con error se
moverán proactivamente con las máquinas virtuales a medida que se transfieran a otro nodo.
¿Es preciso realizar ajustes de sondeo en Windows Server 2012 o Windows Server 2016?
El sondeo de NVMe solo está disponible en Windows Server 2019 en Azure.
¿Puedo volver a un modelo de rutina de servicio de interrupción (ISR) tradicional?
Máquinas virtuales de la serie Lsv2 están optimizadas para el sondeo de NVMe. Se proporcionan
continuamente actualizaciones para mejorar el rendimiento del sondeo.
¿Se puede ajustar la configuración del sondeo en Windows Server 2019?
El usuario no puede ajustar la configuración del sondeo.
Pasos siguientes
Consulte las especificaciones de todas las máquinas virtuales optimizadas para el rendimiento del
almacenamiento en Azure
Tamaños de máquinas virtuales optimizadas para
GPU
Los tamaños de máquina virtual optimizada para GPU son máquinas virtuales especializadas con GPU de
NVIDIA. Estos tamaños están diseñados para cargas de trabajo de proceso intensivo, uso intensivo de gráficos y
visualización. En este artículo se proporciona información sobre el número y el tipo de GPU, vCPU, discos de
datos y NIC. El ancho de banda de red y el rendimiento del almacenamiento también se incluyen para cada
tamaño de esta agrupación.
Los tamaños de NC, NCv2 y NCv3 están optimizados para aplicaciones y algoritmos que usan mucho la
red y el procesador. Algunos ejemplos son las simulaciones y las aplicaciones basadas en CUDA y en
OpenCL, la inteligencia artificial y el aprendizaje profundo. La serie NCv3 se centra en las cargas de
trabajo de informática de alto rendimiento e incorpora la GPU NVIDIA Tesla V100. La serie NC utiliza el
procesador Intel Xeon E5-2690 v3 a 2,60 GHz v3 (Haswell), y las series NCv2 y NCv3 utilizan el
procesador Intel Xeon E5-2690 v4 (Broadwell).
ND y NDv2. La serie ND se centra en escenarios de entrenamiento e inferencia para el aprendizaje
profundo. Utiliza la GPU NVIDIA Tesla P40 y el procesador Intel Xeon E5-2690 v4 (Broadwell). La serie
NDv2 usa el procesador Intel Xeon Platinum 8168 (Skylake).
Los tamaños NV y NVv3 están optimizados y diseñados para escenarios de visualización remota,
streaming, juegos, codificación y VDI mediante plataformas como OpenGL y DirectX. Estas máquinas
virtuales están respaldadas por la GPU NVIDIA Tesla M60.
Serie NC
Las máquinas virtuales de la serie NC funcionan con la tarjeta NVIDIA Tesla K80 y el procesador Intel Xeon E5-
2690 v3 (Haswell). Los usuarios pueden trabajar con datos con mayor rapidez aprovechando CUDA para las
aplicaciones de exploración de energía, simulaciones de accidentes, la representación de trazado de rayos, el
aprendizaje profundo y mucho más. La configuración NC24r proporciona una interfaz de red de baja latencia y
alto rendimiento optimizada para cargas de trabajo de computación paralelas estrechamente unidas.
GIB DE
ALMACENA
MIENTO DISCOS DE
MEMORIA: TEMPORAL MEMORIA DATOS
SIZE VCPU GIB (SSD) GPU DE GPU: GIB MÁX. Nº MÁX. NIC
Standard_N 6 56 340 1 12 24 1
C6
Standard_N 12 112 680 2 24 48 2

C12
Standard_N 24 224 1440 4 48 64 4

C24
GIB DE
ALMACENA
MIENTO DISCOS DE
MEMORIA: TEMPORAL MEMORIA DATOS
SIZE VCPU GIB (SSD) GPU DE GPU: GIB MÁX. Nº MÁX. NIC
Standard_N 24 224 1440 4 48 64 4

C24r*
1 GPU = media tarjeta K80.

*Compatible con RDMA
Serie NCv2
Las VM de la serie NCv2 disponen de tecnología de GPU NVIDIA Tesla P100. Estas GPU pueden duplicar el
rendimiento del trabajo de computación de la serie NC. Los clientes pueden aprovechar estas GPU actualizadas
para cargas de trabajo de HPC tradicionales, como la creación de modelos de embalses, la secuenciación de
ADN, el análisis de proteínas, la realización de simulaciones Monte Carlo y otras. Además de las GPU, las
máquinas virtuales de la serie NCv2 también están equipadas con CPU Intel Xeon E5-2690 v4 (Broadwell).
La configuración NC24rs v2 proporciona una interfaz de red de baja latencia y alto rendimiento optimizada para
cargas de trabajo de computación paralelas estrechamente unidas.
IMPORTANT
Para esta familia de tamaño, la cuota de vCPU (core) en su suscripción está establecida inicialmente en 0 en cada región.
Solicite un aumento de cuota de vCPU para esta familia en una región donde esté disponible.
RENDIMIE
NTO
MÁXIMO
DEL DISCO
SIN
ALMACEN
ALMACEN AMIENTO
AMIENTO EN LA
TEMPORA MEMORIA DISCOS DE CACHÉ:
MEMORIA: L (SSD): DE GPU: DATOS IOPS / Nº MÁX.
SIZE VCPU GIB GIB GPU GIB MÁX. MBPS NIC
Standard_ 6 112 736 1 16 12 20000/ 4

NC6s_v2 200
Standard_ 12 224 1474 2 32 24 40000/40 8

NC12s_v 0
2
Standard_ 24 448 2948 4 64 32 80000/80 8

NC24s_v 0
2
Standard_ 24 448 2948 4 64 32 80000/80 8

NC24rs_v 0
2*
1 GPU = una tarjeta P100.
Serie NCv3
Las VM de la serie NCv3 disponen de tecnología de GPU NVIDIA Tesla V100. Estas GPU pueden aumentar 1,5
veces el rendimiento del trabajo de computación de la serie NCv2. Los clientes pueden aprovechar estas GPU
actualizadas para cargas de trabajo de HPC tradicionales, como la creación de modelos de embalses, la
secuenciación de ADN, el análisis de proteínas, la realización de simulaciones Monte Carlo y otras. La
configuración NC24rs v3 proporciona una interfaz de red de baja latencia y alto rendimiento optimizada para
cargas de trabajo de computación paralelas estrechamente unidas. Además de las GPU, las máquinas virtuales
de la serie NCv3 también están equipadas con CPU Intel Xeon E5-2690 v4 (Broadwell).
IMPORTANT
Para esta familia de tamaño, la cuota de vCPU (core) en su suscripción está establecida inicialmente en 0 en cada región.
RENDIMIE
NTO
MÁXIMO
DEL DISCO
SIN
ALMACEN
ALMACEN AMIENTO
AMIENTO EN LA
TEMPORA MEMORIA DISCOS DE CACHÉ:
MEMORIA: L (SSD): DE GPU: DATOS IOPS / Nº MÁX.
SIZE VCPU GIB GIB GPU GIB MÁX. MBPS NIC
Standard_ 6 112 736 1 16 12 20000/20 4

NC6s_v3 0
Standard_ 12 224 1474 2 32 24 40000/40 8

NC12s_v 0
3
Standard_ 24 448 2948 4 64 32 80000/80 8

NC24s_v 0
3
Standard_ 24 448 2948 4 64 32 80000/80 8

NC24rs_v 0
3*
1 GPU = una tarjeta V100

Serie NDv2 (versión preliminar)

InfiniBand: No compatible
La máquina virtual de la serie NDv2 es una nueva incorporación a la familia de GPU diseñada para las
necesidades de las cargas de informática de alto rendimiento, inteligencia artificial y aprendizaje automático.
Cuenta con 8 GPU NVIDIA Tesla V100 NVLINK interconectadas, 40 núcleos Intel Xeon Platinum 8168
(Skylake) y 672 GiB de memoria del sistema. La instancia de NDv2 proporciona un excelente rendimiento de
FP32 y FP64 para cargas de trabajo de HPC e inteligencia artificial mediante Cuda, TensorFlow, Pytorch, Caffe y
otros marcos.
Regístrese y acceda a estas máquinas durante la versión preliminar.
RENDIMI
ENTO
MÁXIMO
DEL
DISCO
SIN
ALMACE ALMACE
NAMIEN NAMIEN ANCHO
TO DISCOS TO EN LA DE
TEMPOR MEMORI DE CACHÉ: BANDA
MEMORI AL (SSD): A DE DATOS IOPS / DE RED Nº MÁX.
SIZE VCPU A: GIB GIB GPU GPU: GIB MÁX. MBPS MÁX. NIC
Standar 40 672 2948 8 V100 16 32 80000/8 24 000 8

d_ND40 (NVLink) 00 Mbps
s_v2
Serie ND
Las máquinas virtuales de serie ND son una novedad incorporada a la familia GPU diseñada para cargas de
trabajo inteligencia artificial y aprendizaje profundo. Ofrecen un rendimiento excelente para el aprendizaje y la
inferencia. Las instancias de ND funcionan con GPU NVIDIA Tesla P40 y CPU Intel Xeon E5-2690 v4
(Broadwell). Estas instancias brindan un rendimiento excelente para operaciones de punto flotante de precisión
única, para cargas de trabajo de inteligencia artificial que usan Microsoft Cognitive Toolkit, TensorFlow, Caffe y
otros marcos. La serie ND también ofrece una memoria de la GPU de un tamaño muy superior (24 GB ), lo que
permite adaptarse a modelos de redes neurales mucho más grandes. Al igual que la serie NC, la serie ND
presenta una configuración con una baja latencia secundaria, una red de alta productividad mediante RDMA y
conectividad InfiniBand para que pueda ejecutar trabajos de aprendizaje a gran escala que abarquen muchas
GPU.
IMPORTANT
Para esta familia de tamaño, la cuota de vCPU (core) por región en su suscripción está establecida inicialmente en 0.
RENDIMIE
NTO
MÁXIMO
DEL DISCO
SIN
ALMACEN
GIB DE AMIENTO
ALMACEN EN LA
AMIENTO MEMORIA DISCOS DE CACHÉ:
MEMORIA: TEMPORA DE GPU: DATOS IOPS / Nº MÁX.
SIZE VCPU GIB L (SSD) GPU GIB MÁX. MBPS NIC
Standard_ 6 112 736 1 24 12 20000/20 4

ND6s 0
Standard_ 12 224 1474 2 48 24 40000/40 8

ND12s 0
Standard_ 24 448 2948 4 96 32 80000/80 8

ND24s 0
Standard_ 24 448 2948 4 96 32 80000/80 8

ND24rs* 0
1 GPU = una tarjeta de P40.

Serie NV
Las máquinas virtuales de la serie NV dispone de tarjetas GPU Tesla M60 de NVIDIA y tecnología NVIDIA
GRID para aplicaciones aceleradas de escritorio y escritorios virtuales donde los clientes pueden visualizar sus
datos o simulaciones. Los usuarios pueden visualizar sus flujos de trabajo con muchos gráficos en las instancias
de NV para obtener una excelente funcionalidad gráfica y ejecutar, además, cargas de trabajo de precisión
únicas, como la codificación y la representación. Las máquinas virtuales de la serie NV también funcionan con
CPU Intel Xeon E5-2690 v3 (Haswell).
Cada GPU de instancias de NV viene con una licencia de GRID. Esta licencia le ofrece flexibilidad para utilizar
una instancia de NV como estación de trabajo virtual para un solo usuario; también se pueden conectar 25
usuarios simultáneos a la VM para un escenario de aplicación virtual.
GIB DE
ALMACE ESTACIO
NAMIEN DISCOS NES DE APLICACI
TO MEMORI DE TRABAJO ONES
MEMORI TEMPOR A DE DATOS Nº MÁX. VIRTUAL VIRTUAL
SIZE VCPU A: GIB AL (SSD) GPU GPU: GIB MÁX. NIC ES ES
Standar 6 56 340 1 8 24 1 1 25
d_NV6
Standar 12 112 680 2 16 48 2 2 50

d_NV12
Standar 24 224 1440 4 32 64 4 4 100

d_NV24
1 GPU = media tarjeta M60.
Serie NVv3 1
Las máquinas virtuales de la serie NVv3 cuentan con la tecnología de las GPU Nvidia Test M60 y la tecnología
GRID de NVIDIA con CPU Intel E5-2690 v4 (Broadwell). Estas máquinas virtuales están orientadas a escritorios
virtuales y aplicaciones gráficas aceleradas mediante GPU donde los clientes desean ver sus datos, simular
resultados para verlos, trabajar en CAD o representar y transmitir contenido. Además, estas máquinas virtuales
pueden ejecutar cargas de trabajo de precisión única, como la codificación y la representación. Las máquinas
virtuales NVv3 son compatibles con Premium Storage y traen el doble de memoria del sistema (RAM ) si se
comparan con la serie NV anterior.
Cada GPU de las instancias de NVv3 viene con una licencia de GRID. Esta licencia le ofrece flexibilidad para
utilizar una instancia de NV como estación de trabajo virtual para un solo usuario; también se pueden conectar
25 usuarios simultáneos a la VM para un escenario de aplicación virtual.
RENDI
MIENT
O
MÁXIM
O DEL
DISCO
SIN
GIB DE ALMAC ESTACI
ALMAC ENAMIE ONES
ENAMIE NTO EN DE
NTO MEMOR DISCOS LA TRABAJ APLICA
TEMPO IA DE DE CACHÉ: Nº O CIONES
MEMOR RAL GPU: DATOS IOPS / MÁX. VIRTUA VIRTUA
SIZE VCPU IA: GIB (SSD) GPU GIB MÁX. MBPS NIC LES LES
Standa 12 112 320 1 8 12 20000/ 4 1 25

rd_NV 200
12s_v3
Standa 24 224 640 2 16 24 40000/ 8 2 50

rd_NV 400
24s_v3
Standa 48 448 1280 4 32 32 80000/ 8 4 100

rd_NV 800
48s_v3
1 GPU = media tarjeta M60.

1 Las máquinas virtuales de la serie NVv3 cuentan con la tecnología Hyper-Threading de Intel.

vCPU.
máquina virtual en todas las NIC y para todos los destinos. Los límites superiores no están garantizados pero
están diseñados para proporcionar una guía a la hora de seleccionar el tipo correcto de máquina virtual para
la aplicación deseada. El rendimiento de red real dependerá de diversos factores (como, por ejemplo, la
Sistemas operativos y controladores compatibles

Para aprovechar las funcionalidades de GPU de las máquinas virtuales de la serie N de Azure que ejecutan
Windows, deben instalarse controladores de GPU de NVIDIA. La extensión de controlador de GPU de NVIDIA
instala los controladores CUDA de NVIDIA o GRID adecuados en una máquina virtual de la serie N. Instale o
administre la extensión mediante Azure Portal o con herramientas como las plantillas de Azure PowerShell o
Azure Resource Manager. Consulte la documentación de la extensión de controlador de GPU de NVIDIA para
los sistemas operativos compatibles y los pasos de implementación. Para una información general sobre las
extensiones de máquina virtual, consulte Características y extensiones de las máquinas virtuales de Azure.
Si decide instalar manualmente los controladores de GPU de NVIDIA, consulte el artículo sobre la instalación
de controladores GPU de la serie N para Windows para obtener información sobre los sistemas operativos
compatibles y los pasos de verificación e instalación.
Consideraciones de la implementación
Para ver la disponibilidad de máquinas virtuales de la serie N, consulte Productos disponibles por región.
Las máquinas virtuales de la serie N solo se pueden implementar en el modelo de implementación de
Resource Manager.
Las máquinas virtuales de serie N difieren en el tipo de Azure Storage que admiten en sus discos. Las
máquinas virtuales NC y NV solo admiten discos de máquina virtual respaldados por Disk Storage
(HDD ) estándar. Las máquinas virtuales NCv2, NCv3, ND, NDv2 y NVv2 solo admiten discos de
máquina virtual respaldados por Disk Storage (SSD ) Premium.
Si desea implementar más de un pequeño número de máquinas virtuales de la serie N, considere la
posibilidad de usar una suscripción de pago por uso u otras opciones de compra. Si usa una cuenta
gratuita de Azure, solo puede usar un número limitado de núcleos de proceso de Azure.
Es posible que necesite aumentar la cuota de núcleos (por región) de la suscripción de Azure y la cuota
independiente para los núcleos NC, NCv2, NCv3, ND, NDv2, NV o NVv2. Para solicitar un aumento de
cuota, abra una solicitud de soporte técnico al cliente en línea sin cargo alguno. Los límites
predeterminados pueden variar según la categoría de suscripción.
Otros tamaños
Uso general
Proceso optimizado
Memoria optimizada
Pasos siguientes
Instalación de controladores de GPU de NVIDIA en
VM de la serie N con Windows
Para aprovechar las funcionalidades de GPU de las máquinas virtuales de la serie N de Azure que ejecutan
Windows, deben instalarse controladores de GPU de NVIDIA. La extensión de controlador de GPU de NVIDIA
instala los controladores CUDA de NVIDIA o GRID adecuados en una máquina virtual de la serie N. Instale o
administre la extensión mediante Azure Portal o con herramientas como las plantillas de Azure PowerShell o
Azure Resource Manager. Consulte la documentación de la extensión de controlador de GPU de NVIDIA para los
sistemas operativos compatibles y los pasos de implementación.
Si decide instalar manualmente los controladores de GPU, este artículo proporciona pasos de instalación y
verificación, controladores y los sistemas operativos compatibles. También está disponible la información de
instalación manual del controlador para las máquinas virtuales Linux.
Para conocer las especificaciones básicas, las capacidades de almacenamiento y los detalles del disco, consulte
Tamaño de máquinas virtuales para GPU Windows.
Sistemas operativos y controladores compatibles

Controladores NVIDIA Tesla (CUDA )
Los controladores NVIDIA Tesla (CUDA) para máquinas virtuales de las series NC, NCv2, NCv3, ND y NDv2 (y
opcionales para la serie NV ) solo se admiten en las distribuciones de sistemas operativos enumeradas en la tabla
siguiente. Los vínculos de descarga de controladores están actualizados en el momento de la publicación. Para ver
los controladores más recientes, visite el sitio web de NVIDIA.
TIP
Como alternativa a la instalación manual de controladores de CUDA en una máquina virtual de Windows Server, puede
implementar una imagen de Data Science Virtual Machine de Azure. Las ediciones de DSVM para Windows Server 2016
preinstalan los controladores NVIDIA CUDA, la biblioteca CUDA Deep Neural Network Library y otras herramientas.
OS CONTROLADOR
Windows Server 2016 398.75 (.exe)
Windows Server 2012 R2 398.75 (.exe)
Controladores de NVIDIA GRID

Microsoft redistribuye los instaladores del controlador NVIDIA GRID para VM de las series NV y NVv3 que se
emplean como estaciones de trabajo virtuales o para aplicaciones virtuales. Instale estos controladores GRID en
VM de la serie NV de Azure y solo en los sistemas operativos enumerados en la tabla siguiente. Estos
controladores incluyen licencias del software GRID Virtual GPU en Azure. No es necesario configurar un servidor
de licencias de software vGPU NVIDIA.
Tenga en cuenta que la extensión de NVIDIA siempre instalará el controlador más reciente. Aquí se proporcionan
vínculos a la versión anterior para los clientes que tienen dependencias de una versión anterior.
OS CONTROLADOR
Windows Server 2019 GRID 9.1 (431.79) (.exe)
Windows Server 2016 GRID 9.0 (431.02) (.exe)
Windows 10
Windows Server 2012 R2 GRID 9.1 (431.79) (.exe)
Windows Server 2008 R2 GRID 9.0 (431.02) (.exe)
Windows 8
Windows 7
Instalación del controlador

1. Conéctese mediante Escritorio remoto a cada máquina virtual de la serie N.
2. Descargue, extraiga e instale el controlador compatible con su sistema operativo Windows.
Después de la instalación de controladores de GRID en una VM, se requiere un reinicio. Después de la instalación
de controladores de CUDA, no se requiere un reinicio.
Comprobación de la instalación del controlador

Tenga en cuenta que el panel de control de Nvidia solo es accesible con la instalación del controlador GRID. Si ha
instalado controladores CUDA, el panel de control de Nvidia no será visible.
Puede comprobar la instalación del controlador en el Administrador de dispositivos. En el ejemplo siguiente se
muestra una configuración correcta de la tarjeta Tesla K80 en una máquina virtual de Azure NC.
Para consultar el estado del dispositivo de GPU, ejecute la utilidad de línea de comandos smi nvidia que se instala
con el controlador.
1. Abra un símbolo del sistema y cambie al directorio C:\Program Files\NVIDIA Corporation\NVSMI.
2. Ejecute nvidia-smi . Si el controlador está instalado, verá una salida parecida a la siguiente. La utilidad
GPU -Util muestra 0 % , salvo que se esté ejecutando una carga de trabajo de GPU en la máquina virtual.
La versión del controlador y los detalles de GPU pueden ser diferentes de los que se muestran.
Conectividad de red RDMA

La conectividad de red RDMA puede habilitarse en las máquinas virtuales de la serie N que puedan usar RDMA,
como la NC24r, implementadas en el mismo conjunto de disponibilidad o en un único grupo de selección de red
en un conjunto de escalado de máquinas virtuales. En las máquinas virtuales compatibles con RDMA, es necesario
agregar la extensión HpcVmDrivers a las máquinas virtuales para instalar los controladores de dispositivos de red
de Windows necesarios para la conectividad RDMA. Para agregar la extensión de máquina virtual a una máquina
virtual de la serie N habilitada para RDMA, puede usar cmdlets de Azure PowerShell para Azure Resource
Manager.
Para instalar la versión más reciente de la extensión HpcVMDrivers 1.1 en una máquina virtual compatible con
RDMA existente denominada "myVM" en la región de oeste de EE. UU.:
Set-AzVMExtension -ResourceGroupName "myResourceGroup" -Location "westus" -VMName "myVM" -ExtensionName

"HpcVmDrivers" -Publisher "Microsoft.HpcCompute" -Type "HpcVmDrivers" -TypeHandlerVersion "1.1"
Para obtener más información, consulte Características y extensiones de las máquinas virtuales para Windows.
Ahora, la red RDMA admite el tráfico de interfaz de paso de mensajes (MPI) para aplicaciones que se ejecutan con
Microsoft MPI o Intel MPI 5.x.
Pasos siguientes
Los desarrolladores que creen aplicaciones con aceleración por GPU para las GPU Tesla de NVIDIA también
pueden descargar e instalar el último CUDA Toolkit. Para obtener más información, consulte la guía de
instalación de CUDA.
Tamaños de máquina virtual de informática de alto
rendimiento
Las máquinas virtuales (VM ) optimizadas para HPC de Azure están diseñadas para ofrecer un rendimiento de
primer nivel, escalabilidad de MPI y rentabilidad para diversas aplicaciones del mundo real.
Redes InfiniBand para HPC de gran escala

Las máquinas virtuales HBv2 cuentan con la característica Mellanox HDR InfiniBand a 200 GB/s, mientras que
las máquinas virtuales HB y HC cuentan con la característica MeliBox EDR InfiniBand a 100 GB/s. Cada uno de
estos tipos de máquinas virtuales están conectados en un árbol FAT sin bloqueos para un rendimiento de
RDMA optimizado y coherente.
Las máquinas virtuales HBv2 admiten el enrutamiento adaptativo y el transporte conectado dinámico (DCT,
además de los transportes estándar RC y UD ). Estas características mejoran el rendimiento, la escalabilidad y la
coherencia de las aplicaciones, y se recomienda totalmente su uso.
Las máquinas virtuales HBv2, HB y HC son compatibles con los controladores estándar Mellanox/OFED. Como
tal, todos los verbos RDMA y tipos de MPI son compatibles. Cada uno de estos tipos de máquinas virtuales
también admite la descarga basada en hardware de MPI colectiva para aumentar el rendimiento de la
aplicación.
Las máquinas virtuales de la serie H original incluyen la característica 56 GB/s Mellanox FDR InfiniBand. Para
aprovechar la interfaz InfiniBand en la serie H, los clientes deben implementar mediante imágenes oficialmente
específicas para este tipo de VM desde Azure Marketplace.
Serie HBv2
Las máquinas virtuales de la serie HBv2 están optimizadas para aplicaciones impulsadas por el ancho de banda
de la memoria, como la dinámica de fluidos, el análisis de elementos finitos y la simulación de yacimientos. Las
máquinas virtuales HBv2 cuentan con 120 núcleos de procesador AMD EPYC 7742, 4 GB de RAM por núcleo
de CPU y sin multithreading simultáneo. Cada máquina virtual de HBv2 proporciona hasta 340 GB/s de ancho
de banda de memoria y hasta 4 teraFLOPS de proceso FP64.
ANCH FREC
O DE UENC FREC
BAN IA DE UENC REND ALMA
DA FREC TODO IA DE IMIEN COMP CENA
DE UENC S LOS CADA TO DE ATIBI MIEN DISC
MEM IA DE NÚCL NÚCL RDM LIDA TO OS DE NIC
PROC MEM ORIA, CPU EOS EO A D TEMP DATO ETHE
ESAD ORIA EN BASE (GHZ, (GHZ, (GB/S CON ORAL S RNET
SIZE VCPU OR (GB) GB/S (GHZ) PICO) PICO) ) MPI (GB) MÁX. MÁX.
Stan 120 AMD 480 350 2.45 2.45 3.4 200 All 480 8 1
dard EPYC +
_HB1 7742 960
20rs
Serie HB
Las máquinas virtuales de la serie HB están optimizadas para aplicaciones que funcionan con ancho de banda
de la memoria, como la dinámica de fluidos, el análisis explícito de elementos finitos y los modelos de clima. Las
máquinas virtuales HB cuentan con 60 núcleos de procesador AMD EPYC 7551, 4 GB de RAM por núcleo de
CPU y ningún multithreading simultáneo. Una máquina virtual HB proporciona hasta 260 GB/s de ancho de
banda de memoria.
ACU: 199-216
ANCH FREC
O DE UENC FREC
Stan 60 AMD 240 263 2.0 2.55 2.55 100 All 700 4 1
dard EPYC
_HB6 7551
0rs
Serie HC
Las máquinas virtuales de la serie HC están optimizadas para aplicaciones basadas en cálculos intensivos, como
el análisis implícito de elementos finitos, la dinámica molecular y la química computacional. Las máquinas
virtuales HC cuentan con 44 núcleos de procesador Intel Xeon Platinum 8168, 8 GB de RAM por núcleo de
CPU y no tienen hyperthreading. La plataforma Intel Xeon Platinum admite el rico ecosistema de herramientas
de software de Intel, como la biblioteca Intel Math Kernel Library.
ACU: 297-315
ANCH FREC
O DE UENC FREC
Stan 44 Intel 352 191 2.7 3.4 3.7 100 All 700 4 1
dard Xeon
_HC4 Plati
4rs num
8168
Serie H
Las máquinas virtuales de la serie H están optimizadas para aplicaciones basadas en frecuencias alta de CPU o
requisitos de gran cantidad de memoria por núcleo. Las máquinas virtuales de la serie H cuentan con 8 o
16 núcleos de procesador Intel Xeon E5 2667 v3, hasta 14 GB de RAM por núcleo de CPU y no tienen
hyperthreading. Una máquina virtual de la serie H proporciona hasta 80 GB/s de ancho de banda de memoria.
ACU: 290-300
ANCH FREC
O DE UENC FREC
Stan 8 Intel 56 40 3.2 3.3 3.6 - Intel 1000 32 2

dard Xeon 5.x,
_H8 E5 MS-
2667 MPI
v3
Stan 16 Intel 112 80 3.2 3.3 3.6 - Intel 2000 64 4

dard Xeon 5.x,
_H16 E5 MS-
2667 MPI
v3
Stan 8 Intel 112 40 3.2 3.3 3.6 - Intel 1000 32 2

dard Xeon 5.x,
_H8 E5 MS-
m 2667 MPI
v3
Stan 16 Intel 224 80 3.2 3.3 3.6 - Intel 2000 64 4

dard Xeon 5.x,
_H16 E5 MS-
m 2667 MPI
v3
Stan 16 Intel 112 80 3.2 3.3 3.6 56 Intel 2000 64 4

dard Xeon 5.x,
_H16 E5 MS-
r1 2667 MPI
v3
Stan 16 Intel 224 80 3.2 3.3 3.6 56 Intel 2000 64 4

dard Xeon 5.x,
_H16 E5 MS-
mr 1 2667 MPI
v3
1 Para las aplicaciones MPI, la red de back-end RDMA dedicada está habilitada por la red InfiniBand FDR.
de disco de datos en caché, el modo de caché del host está establecido en ReadOnly o ReadWrite. En el
caso de la operación de disco de datos no en caché, el modo de caché del host está definido en None.
vCPU.
máquina virtual en todas las NIC y para todos los destinos. Los límites superiores no están garantizados
pero están diseñados para proporcionar una guía a la hora de seleccionar el tipo correcto de máquina virtual
para la aplicación deseada. El rendimiento de red real dependerá de diversos factores (como, por ejemplo, la
Consideraciones de la implementación
Suscripción de Azure: para implementar más que algunas instancias de proceso intensivo, considere la
posibilidad de usar una suscripción de pago por uso u otras opciones de compra. Si usa una cuenta
gratuita de Azure, solo puede usar un número limitado de núcleos de proceso de Azure.
Disponibilidad y precios: los tamaños de máquina virtual se ofrecen solo en el plan de tarifa estándar.
Para ver la disponibilidad en las regiones de Azure, consulte Productos disponibles por región .
Cuota de núcleos: quizás tenga que aumentar la cuota de núcleos de su suscripción de Azure partiendo
del valor predeterminado. La suscripción también podría limitar el número de núcleos que se pueden
implementar en ciertas familias de tamaño de máquina virtual, como la serie H. Para solicitar un
aumento de cuota, abra una solicitud de soporte técnico al cliente en línea sin cargo alguno. (Los límites
predeterminados pueden variar según la categoría de suscripción).
NOTE
Si tiene necesidades de capacidad a gran escala, póngase en contacto con el soporte técnico de Azure. Las cuotas
de Azure son límites de crédito, no garantías de capacidad. Independientemente de la cuota, solamente se le
cobrarán los núcleos que use.
Red virtual : no se necesita una red virtual de Azure para usar instancias de proceso intensivo. Sin
embargo, para muchas implementaciones necesita al menos una red virtual de Azure basada en la nube
o una conexión de sitio a sitio si necesita acceder a recursos locales. Si es necesario, cree una red virtual
para implementar las instancias. No se admite la adición de máquinas virtuales de proceso intensivo a las
redes virtuales de grupos de afinidad.
Cambio de tamaño: debido a su hardware especializado, solo se puede cambiar el tamaño de las
instancias de proceso intensivo dentro de la misma familia de tamaño (serie H o serie A de proceso
intensivo). Por ejemplo, una máquina virtual de la serie H solo se puede cambiar de un tamaño de serie
H a otro. Además, no se admite el cambio de tamaño de un tamaño que no sea de proceso intensivo a un
tamaño que sí lo sea.
Instancias compatibles con RDMA

Un subconjunto de las instancias de proceso intensivo (A8, A9, H16r, H16mr, HB y HC ) incluye una interfaz de
red para la conectividad de acceso directo a memoria remota (RDMA). Tamaños seleccionados de la serie N
designados con la letra "r", como las configuraciones de NC24rs (NC24rs_v2 y NC24rs_v3) también son
compatibles con RDMA. Esta interfaz se añade a la interfaz de red estándar de Azure disponible para otros
tamaños de máquina virtual.
Esta interfaz permite que las instancias compatibles con RDMA se comuniquen través de una red InfiniBand
(IB ), que funciona a velocidades EDR en las series HB y HC, a velocidades FDR en máquinas virtuales H16r,
H16mr y de la serie N compatibles con RDMA, y a velocidades QDR en máquinas virtuales A8 y A9. Estas
funcionalidades RDMA pueden mejorar la escalabilidad y el rendimiento de determinadas aplicaciones de la
Interfaz de paso de mensajes (MPI). Para más información acerca de la velocidad, consulte los detalles en las
tablas de esta página.
NOTE
En Azure, solo se admite IP sobre IB en VM habilitadas para SR-IOV (SR-IOV para InfiniBand, actualmente, HB y HC).
RDMA a través de IB se admite en todas las instancias compatibles con RDMA.
Sistema operativo: Windows Server 2016 en todas las máquinas virtuales de la serie HPC anterior.
Windows Server 2012 R2 y Windows Server 2012 también se admiten en las máquinas virtuales no
habilitadas para SR -IOV (de ahí que se excluyan HB y HC ).
MPI: los tamaños de máquina virtual habilitados para SR -IOV en Azure (HB, HC ) permiten que se use
prácticamente cualquier tipo de MPI con Mellanox OFED. En las máquinas virtuales en que no está
habilitado SR -IOV, las implementaciones de MPI compatibles usan la interfaz Microsoft Network Direct
(ND ) para comunicarse entre las instancias. Por lo tanto, solo se admiten las versiones de Microsoft MPI
(MS -MPI) 2012 R2 o posterior e Intel MPI 5.x. Las versiones posteriores (2017 y 2018) de la biblioteca
en tiempo de ejecución de MPI pueden ser o no compatibles con los controladores de Azure RDMA.
Extensión de VM InfiniBandDriverWindows: en las máquinas virtuales compatibles con RDMA,
agregue la extensión InfiniBandDriverWindows para habilitar InfiniBand. Esta extensión de máquina
virtual instala controladores Windows Network Direct (en máquinas virtuales sin SR -IOV ) o
controladores Mellanox OFED (en máquinas virtuales con SR -IOV ) para la conectividad RDMA. En
algunas implementaciones de las instancias A8 y A9, la extensión HpcVmDrivers se agrega
automáticamente. Tenga en cuenta que la extensión de máquina virtual HpcVmDrivers está en desuso,
por lo que no se actualizará. Para agregar la extensión de máquina virtual a una máquina virtual, puede
usar los cmdlets de Azure PowerShell.
El comando siguiente instala la versión más reciente de la extensión InfiniBandDriverWindows, la versión
1.0, en una máquina virtual compatible con RDMA existente denominada myVM implementada en el
grupo de recursos denominado myResourceGroup de la región Oeste de EE. UU. :
Set-AzVMExtension -ResourceGroupName "myResourceGroup" -Location "westus" -VMName "myVM" -

ExtensionName "InfiniBandDriverWindows" -Publisher "Microsoft.HpcCompute" -Type
"InfiniBandDriverWindows" -TypeHandlerVersion "1.0"
Como alternativa, se pueden incluir extensiones de máquina virtual en las plantillas de Azure Resource
Manager para facilitar la implementación, con el siguiente elemento JSON:
"properties":{
"publisher": "Microsoft.HpcCompute",
"type": "InfiniBandDriverWindows",
"typeHandlerVersion": "1.0",
}
El comando siguiente instala la versión más reciente de la extensión InfiniBandDriverWindows, la versión

1.0, en todas las máquinas virtuales compatibles con RDMA en un conjunto de escalado de máquina
virtual denominado myVMSS implementado en el grupo de recursos denominado myResourceGroup:
$VMSS = Get-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myVMSS"

Add-AzVmssExtension -VirtualMachineScaleSet $VMSS -Name "InfiniBandDriverWindows" -Publisher
"Microsoft.HpcCompute" -Type "InfiniBandDriverWindows" -TypeHandlerVersion "1.0"
Update-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "MyVMSS" -VirtualMachineScaleSet
$VMSS
Update-AzVmssInstance -ResourceGroupName "myResourceGroup" -VMScaleSetName "myVMSS" -InstanceId "*"
Para obtener más información, consulte el artículo de características y extensiones de las máquinas
virtuales. También puede trabajar con las extensiones para las máquinas virtuales implementadas en el
modelo de implementación clásica.
Espacio de direcciones de red RDMA : la red RDMA en Azure reserva el espacio de direcciones
172.16.0.0/16. Para ejecutar aplicaciones MPI en instancias implementadas en una red virtual Azure,
asegúrese de que el espacio de direcciones de la red virtual no se superpone a la red RDMA.
Opciones de configuración del clúster
Azure ofrece varias opciones para crear clústeres de máquinas virtuales de HPC de Windows que se pueden
comunicar con la red RDMA, incluidos:
Máquinas virtuales: implemente las máquinas virtuales de HPC compatibles con RDMA en el mismo
conjunto de disponibilidad (cuando use el modelo de implementación de Azure Resource Manager). Si
usa el modelo de implementación clásica, implemente las máquinas virtuales en el mismo servicio en la
nube.
Conjuntos de escalado de máquinas virtuales: en un conjunto de escalado de máquinas virtuales,
asegúrese de limitar la implementación a un único grupo de selección de ubicación. Por ejemplo, en una
plantilla de Resource Manager, establezca la propiedad singlePlacementGroup en true .
MPI entre las máquinas virtuales: si es necesaria la comunicación de MPI entre las máquinas
virtuales, asegúrese de que las máquinas virtuales estén en el mismo conjunto de disponibilidad o en el
mismo conjunto de escalado de la máquina virtual.
Azure CycleCloud: cree un clúster de HPC en Azure CycleCloud para ejecutar trabajos MPI en nodos
de Windows.
Azure Batch: cree un grupo de Azure Batch para ejecutar cargas de trabajo MPI en nodos de proceso de
Windows Server. Para más información, consulte Uso de instancias compatibles con RDMA o habilitadas
para GPU en grupos de Batch. Consulte también el proyecto Batch Shipyard para ejecutar cargas de
trabajo basadas en contenedores en Batch.
Microsoft HPC Pack: HPC Pack incluye un entorno de tiempo de ejecución para MS -MPI que usa la red
RDMA de Azure cuando se implementa en máquinas virtuales de Windows compatibles con RDMA. -
Para obtener ejemplos de implementación, consulte la Configuración de un clúster de Windows RDMA
con HPC Pack para ejecutar aplicaciones MPI.
Otros tamaños
Uso general
Proceso optimizado
Memoria optimizada
GPU optimizada
Pasos siguientes
Para ver listas de comprobación para usar instancias de proceso intensivo con HPC Pack en Windows
Server, consulte Configuración de un clúster de Windows RDMA con HPC Pack para ejecutar
aplicaciones MPI.
Para usar instancias de proceso intensivo para ejecutar aplicaciones MPI con Azure Batch, consulte Uso
de tareas de instancias múltiples para ejecutar aplicaciones de la Interfaz de paso de mensajes (MPI) en
Azure Batch.
Generaciones anteriores de tamaños de máquina
virtual
En esta sección se proporciona información sobre las generaciones anteriores de tamaños de máquina virtual. Se
pueden seguir usando estos tamaños, pero hay generaciones más recientes disponibles.
Serie F
La serie F se basa en el procesador Intel Xeon® E5-2673 v3 (Haswell) de 2,4 GHz, que puede alcanzar
velocidades de reloj de hasta 3,1 GHz con Intel Turbo Boost Technology 2.0. Este es el mismo rendimiento de
CPU que el de la serie Dv2 de máquinas virtuales.
Las máquinas virtuales de la serie F son una opción excelente para cargas de trabajo que exigen CPU más
rápidas, pero que no necesitan tanta memoria o almacenamiento temporal por vCPU. Las cargas de trabajo,
como análisis, servidores de juegos, servidores web y procesamiento por lotes se beneficiarán del valor de la
serie F.
ACU: 210 - 250
RENDIMIENTO
MÁXIMO DE
ALMACENAMIE
NTO
Standard_F1 1 2 16 3000 / 46 / 4 / 4x500 2 / 750

23
Standard_F2 2 4 32 6000 / 93 / 8 / 8x500 2 / 1500

46
Standard_F4 4 8 64 12000 / 187 / 16 / 16x500 4 / 3000

93
Standard_F8 8 16 128 24000 / 375 / 32 / 32x500 8 / 6000

187
Standard_F16 16 32 256 48000 / 750 / 64 / 64x500 8 / 12 000

375
Serie Fs 1
La serie Fs proporciona todas las ventajas de la serie F, además de Premium Storage.
ACU: 210 - 250
RENDIMIENT
O MÁXIMO
DE
ALMACENA RENDIMIENT
MIENTO O MÁXIMO
Standard_F 1 2 4 4 4000/32 3200/48 2 / 750

1s (12)
Standard_F 2 4 8 8 8000/64 6400/96 2 / 1500

2s (24)
Standard_F 4 8 16 16 16000/128 12800/192 4 / 3000

4s (48)
Standard_F 8 16 32 32 32000/256 25600/384 8 / 6000

8s (96)
Standard_F 16 32 64 64 64000/512 51200/768 8 / 12 000

16s (192)
MBps = 10^6 bytes por segundo y GiB = 1024^3 bytes.

1 El rendimiento de disco máximo ( IOPS o MBps) posible con una máquina virtual de la serie Fs puede estar
Serie NVv2
Recomendación de tamaño más reciente: Serie NVv3
Las máquinas virtuales de la serie NVv2 cuentan con la tecnología de las GPU Nvidia Test M60 y la tecnología
GRID de NVIDIA con CPU Intel Broadwell. Estas máquinas virtuales están orientadas a escritorios virtuales y
aplicaciones gráficas aceleradas mediante GPU donde los clientes desean ver sus datos, simular resultados para
verlos, trabajar en CAD o representar y transmitir contenido. Además, estas máquinas virtuales pueden ejecutar
cargas de trabajo de precisión única, como la codificación y la representación. Las máquinas virtuales NVv2 son
compatibles con Premium Storage y traen el doble de memoria del sistema (RAM ) si se comparan con la serie
NV anterior.
Cada GPU de las instancias de NVv2 viene con una licencia de GRID. Esta licencia le ofrece flexibilidad para
utilizar una instancia de NV como estación de trabajo virtual para un solo usuario; también se pueden conectar
25 usuarios simultáneos a la VM para un escenario de aplicación virtual.
GIB DE
ALMACE ESTACIO
NAMIEN DISCOS NES DE APLICACI
TO MEMORI DE TRABAJO ONES
MEMORI TEMPOR A DE DATOS Nº MÁX. VIRTUAL VIRTUAL
SIZE VCPU A: GIB AL (SSD) GPU GPU: GIB MÁX. NIC ES ES
Standar 6 112 320 1 8 12 4 1 25

d_NV6s
_v2
Standar 12 224 640 2 16 24 8 2 50

d_NV12
s_v2
Standar 24 448 1280 4 32 32 8 4 100

d_NV24
s_v2

vCPU.
Generaciones anteriores de tamaños de máquina virtual

En esta sección se proporciona información sobre las generaciones anteriores de tamaños de máquina virtual.
Estos tamaños todavía se admiten, pero no recibirán capacidad adicional. Hay tamaños alternativos o versiones
más recientes que están disponibles con carácter general. Consulte Tamaños de las máquinas virtuales Windows
en Azure o Tamaños de las máquinas virtuales Linux en Azure para elegir el tamaño de máquina virtual que
mejor se ajuste a sus necesidades.
Para más información sobre el cambio de tamaño una máquina virtual Linux, consulte Cambiar el tamaño de
una máquina virtual Linux que usa la CLI de Azure. Si está usando máquinas virtuales Windows y prefiere usar
PowerShell, consulte Cambio de tamaño de una máquina virtual Windows.
A básico
Recomendación de tamaño más reciente: Serie Av2
Los tamaños de niveles básicos se utilizan sobre todo para cargas de trabajo de desarrollo y otras aplicaciones
que no requieren equilibrio de carga, escalado automático o máquinas virtuales de uso intensivo de memoria.
TAMAÑO MÁX. DISCOS

TAMAÑO – MÁXIMO DEL DE DATOS
TAMAÑO\NOM DISCO (1023 GB CADA MÁX. E/S (300
BRE VCPU MEMORIA NICS (MÁX) TEMPORAL UNO) POR DISCO)
A0\Basic_A0 1 768 MB 2 20 GB 1 1x300
A1\Basic_A1 1 1,75 GB 2 40 GB 2 2x300
A2\Basic_A2 2 3,5 GB 2 60 GB 4 4x300
A3\Basic_A3 4 7 GB 2 120 GB 8 8x300
A4\Basic_A4 8 14 GB 2 240 GB 16 16x300
Standard_A0 - A4 con CLI y PowerShell

En el modelo de implementación clásica, algunos nombres de tamaños de VM varían ligeramente en la CLI y en
PowerShell:
Standard_A0 es ExtraSmall
Standard_A1 es Small
Standard_A2 es Medium
Standard_A3 es Large
Standard_A4 es ExtraLarge
Serie A
ACU: 50-100
Nº MÁX. DE
ALMACENAMIE RENDIMIENTO NIC/ANCHO DE
NTO DE DISCOS DE BANDA DE RED
TEMPORAL DISCOS DE DATOS MÁX.: ESPERADO
SIZE VCPU MEMORIA: GIB (HDD): GIB DATOS MÁX. E/S (MBPS)
Standard_A0 1 0,768 20 1 1x500 2 / 100

1
Standard_A1 1 1,75 70 2 2 x 500 2 / 500
Standard_A2 2 3,5 135 4 4x500 2 / 500

Nº MÁX. DE
ALMACENAMIE RENDIMIENTO NIC/ANCHO DE
NTO DE DISCOS DE BANDA DE RED
TEMPORAL DISCOS DE DATOS MÁX.: ESPERADO
SIZE VCPU MEMORIA: GIB (HDD): GIB DATOS MÁX. E/S (MBPS)
Standard_A3 4 7 285 8 8x500 2 / 1000
Standard_A4 8 14 605 16 16x500 4 / 2000
Standard_A5 2 14 135 4 4x500 2 / 500
Standard_A6 4 28 285 8 8x500 2 / 1000
Standard_A7 8 56 605 16 16x500 4 / 2000
1 La suscripción del tamaño A0 es excesiva en el hardware físico. Solo en este tamaño específico, las
implementaciones de otros clientes podrían afectar el rendimiento de la carga de trabajo en ejecución. A
continuación, se indica el rendimiento relativo como la línea base esperada, sujeta a una variabilidad aproximada
de 15 por ciento.
Serie A: instancias de proceso intensivo

ACU: 225
Los tamaños A8-A11 los de la serie H también se conocen como instancias de proceso intensivo. El hardware
que ejecuta estos tamaños está diseñado y optimizado para aplicaciones de proceso intensivo que consumen
muchos recursos de red, incluidas las aplicaciones de clúster de proceso de alto rendimiento (HPC ), el modelado
y las simulaciones. La serie A8-A11 utiliza Intel Xeon E5-2670 a 2,6 GHz y la serie H, Intel Xeon E5-2667 v3 a 3,2
GHz.
ALMACENAMIE RENDIMIENTO
NTO DE DISCOS DE
TEMPORAL DISCOS DE DATOS MÁX.:
SIZE VCPU MEMORIA: GIB (HDD): GIB DATOS MÁX. E/S Nº MÁX. NIC
Standard_A8 8 56 382 32 32x500 2

1
Standard_A9 16 112 382 64 64x500 4

1
Standard_A10 8 56 382 32 32x500 2
Standard_A11 16 112 382 64 64x500 4
1Para las aplicacionesMPI, la red de back-end RDMA dedicada está habilitada por la red InfiniBand FDR, que
ofrece una latencia sumamente baja y un alto ancho de banda.
Serie D
Recomendación de tamaño más reciente: Serie Dv3
ACU: 160-250 1
RENDIMIENTO
MÁXIMO DE
ALMACENAMIE
NTO
Standard_D1 1 3,5 50 3000 / 46 / 4 / 4x500 2 / 500

23
Standard_D2 2 7 100 6000 / 93 / 8 / 8x500 2 / 1000

46
Standard_D3 4 14 200 12000 / 187 / 16 / 16x500 4 / 2000

93
Standard_D4 8 28 400 24000 / 375 / 32 / 32x500 8 / 4000

187
1 La familia de máquinas virtuales se puede ejecutar

en una de las CPU siguientes: 2.2 GHz Intel Xeon® E5-2660
v2, 2,4 GHz Intel Xeon® E5-2673 v3 (Haswell) de 2,3 GHz Intel XEON® o E5-2673 v4 (Broadwell)
Serie D: con optimización para memoria

Recomendación de tamaño más reciente: Serie Dv3
ACU: 160-250 1
RENDIMIENTO
MÁXIMO DE
ALMACENAMIE
NTO
Standard_D11 2 14 100 6000 / 93 / 8 / 8x500 2 / 1000

46
Standard_D12 4 28 200 12000 / 187 / 16 / 16x500 4 / 2000

93
RENDIMIENTO
MÁXIMO DE
ALMACENAMIE
NTO
Standard_D13 8 56 400 24000 / 375 / 32 / 32x500 8 / 4000

187
Standard_D14 16 112 800 48000 / 750 / 64 / 64x500 8 / 8000

375

v2, 2,4 GHz Intel Xeon® E5 2673 v3 Haswell de 2,3 GHz Intel XEON® o E5-2673 v4 (Broadwell)
- ( )
Serie DS
Recomendación de tamaño más reciente: Serie DSv3
ACU: 160-250 1
RENDIMIENT
O MÁXIMO
DE
ALMACENA RENDIMIENT
MIENTO O MÁXIMO
Standard_D 1 3,5 7 4 4000 / 32 3200 / 32 2 / 500

S1 (43)
Standard_D 2 7 14 8 8000 / 64 6400 / 64 2 / 1000

S2 (86)
Standard_D 4 14 28 16 16 000 / 12 800 / 4 / 2000

S3 128 (172) 128
Standard_D 8 28 56 32 32 000 / 25 600 / 8 / 4000

S4 256 (344) 256

Serie DS: con optimización para memoria

Recomendación de tamaño más reciente: Serie DSv3
ACU: 160-250 1,2
RENDIMIENT
O MÁXIMO
DE
ALMACENA RENDIMIENT
MIENTO O MÁXIMO
Standard_D 2 14 28 8 8000 / 64 6400 / 64 2 / 1000

S11 (72)
Standard_D 4 28 56 16 16 000 / 12 800 / 4 / 2000

S12 128 (144) 128
Standard_D 8 56 112 32 32 000 / 25 600 / 8 / 4000

S13 256 (288) 256
Standard_D 16 112 224 64 64 000 / 51 200 / 8 / 8000

S14 512 (576) 512
1 El rendimiento de disco máx. ( E/Spor segundo o Mbps) posible con una VM de la serie DS puede estar
2 La familia de máquinas virtuales se puede ejecutar en una de las CPU siguientes: 2.2 GHz Intel Xeon® E5 -2660
Serie Ls
La serie LS ofrece hasta 32 vCPU, con el procesador Intel® Xeon® de la familia E5 v3. La serie LS obtiene el
mismo rendimiento de CPU que las series G/GS y viene con 8 GiB de memoria por vCPU.
La serie Ls no permite crear una memoria caché local para aumentar el número de IOPS que pueden alcanzar
los discos de datos duraderos. El alto rendimiento y el elevado número de IOPS del disco local hace que las
máquinas virtuales de la serie Ls sean ideales para almacenes NoSQL, como Apache Cassandra y MongoDB,
que replican datos en diferentes máquinas virtuales para garantizar la persistencia en caso de que se produzca
un error en una máquina virtual.
ACU: 180-240
RENDIMIENT RENDIMIENT
O MÁXIMO O DE DISCO Nº MÁX. DE
DE NO EN NIC/ANCHO
ALMACENA ALMACENA CACHÉ MÁX. DE BANDA
MIENTO DISCOS DE MIENTO (E/S POR DE RED
MEMORIA TEMPORAL DATOS TEMPORAL SEGUNDO/ ESPERADO
SIZE VCPU (GIB) (GIB) MÁX. (IOPS/MBPS) MBPS) (MBPS)
Standard_L 4 32 678 16 20000/200 5000/125 2 / 4000

4s
RENDIMIENT RENDIMIENT
O MÁXIMO O DE DISCO Nº MÁX. DE
DE NO EN NIC/ANCHO
ALMACENA ALMACENA CACHÉ MÁX. DE BANDA
MIENTO DISCOS DE MIENTO (E/S POR DE RED
MEMORIA TEMPORAL DATOS TEMPORAL SEGUNDO/ ESPERADO
SIZE VCPU (GIB) (GIB) MÁX. (IOPS/MBPS) MBPS) (MBPS)
Standard_L 8 64 1388 32 40000/400 10000/250 4 / 8000

8s
Standard_L 16 128 2807 64 80000/800 20000/500 8 / 16000

16s
Standard_L 32 256 5630 64 160000/16 40000/100 8 / 20000

32s 1 00 0
El rendimiento máximo de disco que es posible con una VM de la serie Ls puede estar limitado por el número, el
tamaño y la fragmentación de cualquier disco asociado. Para información detallada, consulte Azure Premium
Storage: Diseño de alto rendimiento.
Serie GS
ACU: 180 - 240 1
RENDIMIENT
O MÁXIMO
DE
ALMACENA RENDIMIENT
MIENTO O MÁXIMO
Standard_G 2 28 56 8 10 000 / 5000 / 125 2 / 2000

S1 100 (264)
Standard_G 4 56 112 16 20 000 / 10 000 / 2 / 4000

S2 200 (528) 250
Standard_G 8 112 224 32 40 000 / 20 000 / 4 / 8000

S3 400 (1056) 500
Standard_G 16 224 448 64 80 000 / 40 000 / 8 / 16000

S4 3 800 (2112) 1000
Standard_G 32 448 896 64 160 000 / 80 000 / 8 / 20000

S5 2, 3 1600 2000
(4224)
1 El rendimiento de disco máx. ( E/S

por segundo o Mbps) posible con una VM de la serie GS puede estar
2
Serie G
ACU: 180 - 240
RENDIMIENTO
MÁXIMO DE
ALMACENAMIE
NTO
Standard_G1 2 28 384 6000 / 93 / 8 / 8 x 500 2 / 2000

46
Standard_G2 4 56 768 12000 / 187 / 16 / 16 x 500 2 / 4000

93
Standard_G3 8 112 1536 24000 / 375 / 32 / 32 x 500 4 / 8000

187
Standard_G4 16 224 3072 48000 / 750 / 64 / 64 x 500 8 / 16000

375
Standard_G5 32 448 6144 96000 / 1500 64 / 64 x 500 8 / 20000

1 / 750
Otros tamaños
Uso general
Proceso optimizado
Memoria optimizada
GPU
Pasos siguientes
Aislamiento de máquina virtual de Azure
Azure Compute ofrece tamaños de máquinas virtuales que están aislados para un tipo concreto de hardware y
dedicados a un solo cliente. Estos tamaños de máquina virtual son más adecuados para cargas de trabajo que
requieren un alto grado de aislamiento de otros clientes como, por ejemplo, las cargas de trabajo que incluyen
elementos como el cumplimiento normativo y los requisitos legales. Los clientes también puede elegir subdividir
aún más los recursos de estas máquinas virtuales aisladas mediante la compatibilidad de Azure para máquinas
virtuales anidadas.
Usar un tamaño aislado garantiza que la máquina virtual será la única que se ejecute en esa instancia de servidor
específica. Las ofertas de máquinas virtuales aisladas actuales incluyen:
Standard_E64is_v3
Standard_E64i_v3
Standard_M128ms
Standard_GS5
Standard_G5
Standard_DS15_v2
Standard_D15_v2
Standard_F72s_v2
Puede más información sobre cada tamaño aislado disponible aquí.
Pasos siguientes
Puede implementar un host dedicado mediante Azure PowerShell, el portal y la CLI de Azure. Para obtener más
detalles, consulte la introducción a los hosts dedicados.
Unidad de proceso de Azure (ACU)
El concepto de unidad de proceso de Azure (ACU ) ofrece una forma de comparar el rendimiento de los
procesos (CPU ) en todas las SKU de Azure. Esto le ayudará a identificar fácilmente el SKU que tiene más
probabilidades de satisfacer sus necesidades de rendimiento. Actualmente, una ACU está estandarizada en
una máquina virtual pequeña (Standard_A1) como 100 y todas las demás SKU representan,
aproximadamente, qué tanto más rápido esa SKU puede ejecutar una prueba comparativa estándar.
IMPORTANT
La ACU es solo una referencia. Los resultados de la carga de trabajo pueden variar.
FAMILIA DE SKU ACU \ VCPU VCPU: NÚCLEO
A0 50 1:1
A1 - A4 100 1:1
A5 - A7 100 1:1
A1_v2 - A8_v2 100 1:1
A2m_v2 - A8m_v2 100 1:1
A8 - A11 225* 1:1
D1 - D14 160 - 250 1:1
D1_v2 - D15_v2 210 - 250* 1:1
DS1 - DS14 160 - 250 1:1
DS1_v2 - DS15_v2 210 - 250* 1:1
D_v3 160 - 190* 2:1***
Ds_v3 160 - 190* 2:1***
E_v3 160 - 190* 2:1***
Es_v3 160 - 190* 2:1***
F2s_v2 - F72s_v2 195 - 210* 2:1***
F1 - F16 210 - 250* 1:1

FAMILIA DE SKU ACU \ VCPU VCPU: NÚCLEO
F1s - F16s 210 - 250* 1:1
G1 - G5 180 - 240* 1:1
GS1 - GS5 180 - 240* 1:1
H 290 - 300* 1:1
HB 199 - 216** 1:1
HC 297 - 315* 1:1
L4s - L32s 180 - 240* 1:1
L8s_v2 - L80s_v2 150 - 175** 2:1
M 160 - 180 2:1***
*Las ACU usan la tecnología Intel® Turbo para incrementar la frecuencia de CPU y brindar una mejora del
rendimiento. El volumen de mejora del rendimiento puede variar según el tamaño de la máquina virtual, la
carga de trabajo y las otras cargas de trabajo que se ejecutan en el mismo host.
**Las ACU usan la tecnología AMD® Boost para incrementar la frecuencia de CPU y brindar una mejora del
rendimiento. El volumen de mejora del rendimiento puede variar según el tamaño de la máquina virtual, la
carga de trabajo y las otras cargas de trabajo que se ejecutan en el mismo host.
***Con Hyper-Threading y capaz de ejecutar la virtualización anidada
Estos son algunos vínculos con información sobre los distintos tamaños:
Uso general
Memoria optimizada
Proceso optimizado
GPU optimizada
Puntuaciones de pruebas comparativas de proceso
para máquinas virtuales Windows
Las siguientes puntuaciones de pruebas comparativas SPECInt muestran el rendimiento de proceso para
máquinas virtuales específicas que ejecutan Windows Server. Las puntuaciones de pruebas comparativas de
proceso también están disponibles para las máquinas virtuales Linux.
Av2: proceso general

TASA BASE
SIZE VCPU NODOS NUMA CPU EJECUCIONES PROMEDIO STDDEV
Standard_A1_ 1 1 Intel(R) 12 14,2 0,3

v2 Xeon(R) CPU
E5-2660 0 a
2,20 GHz
Standard_A1_ 1 1 Intel(R) 9 13.2 0.6

v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
Standard_A1_ 1 1 Intel(R) 10 14,1 0,7

v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Standard_A2_ 2 1 Intel(R) 14 28,9 0.6

v2 Xeon(R) CPU
E5-2660 0 a
2,20 GHz

v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Standard_A2 2 1 Intel(R) 14 29,0 0,5

m_v2 Xeon(R) CPU
E5-2660 0 a
2,20 GHz
Standard_A2 2 1 Intel(R) 11 26,3 0.8

m_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
TASA BASE

m_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

v2 Xeon(R) CPU
E5-2660 0 a
2,20 GHz

v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
Standard_A4_ 4 1 Intel(R) 15 52,1 4.5.

v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

m_v2 Xeon(R) CPU
E5-2660 0 a
2,20 GHz

m_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

m_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

v2 Xeon(R) CPU
E5-2660 0 a
2,20 GHz

v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

m_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
TASA BASE
Standard_A8 8 1 Intel(R) 10 104,5 5,1

m_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

m_v2 Xeon(R) CPU
E5-2660 0 a
2,20 GHz
B: ampliables
TASA BASE
Standard_B1 1 1 Intel(R) 9 6.3 0,2

ms Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
Standard_B1 1 1 Intel(R) 47 6.4. 0,2

ms Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Standard_B2 2 1 Intel(R) 36 19,8 0.8

ms Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Standard_B2s 2 1 Intel(R) 2 13.0 0.0

Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
Standard_B2s 2 1 Intel(R) 29 13.0 0,5

Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

ms Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
Standard_B4 4 1 Intel(R) 43 28,3 0,7

ms Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

ms Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
TASA BASE

ms Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
DSv3: proceso general y almacenamiento Premium

TASA BASE
Standard_D2s 2 1 Intel(R) 10 40.8 2.3

_v3 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
Standard_D2s 2 1 Intel(R) 52 43,3 2.1

_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

_v3 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

_v3 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Standard_D16 16 1 Intel(R) 3 275,7 5,1

s_v3 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
Standard_D16 16 1 Intel(R) 38 298,2 4.4.

s_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Standard_D32 32 1 Intel(R) 24 545,8 10.5

s_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
TASA BASE

s_v3 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

s_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Dv3: proceso general

TASA BASE
Standard_D2_ 2 1 Intel(R) 10 38,6 1.8

v3 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

v3 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
Standard_D4_ 4 1 Intel(R) 45 82,7 4.5.

v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Standard_D8_ 8 1 Intel(R) 9 146,7 10,4

v3 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

_v3 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
TASA BASE

_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

_v3 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
DSv2: optimizada para almacenamiento

TASA BASE
Standard_DS1 1 1 Intel(R) 12 33,0 1.1

_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
TASA BASE

_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Standard_DS5 16 1 Intel(R) 11 414,9 5,1

_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

1_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

1_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

1-1_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

1-1_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

2_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

2_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

2-1_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

2-1_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
TASA BASE

2-2_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
Standard_DS1 2 1 Intel(R) 33 67,7 5,1

2-2_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

3_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

3_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

3-2_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

3-2_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

3-4_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

3-4_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

4_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

4_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

4-4_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
TASA BASE

4-4_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

4-8_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

4-8_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

5_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
Dv2: proceso general

TASA BASE

v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
Standard_D1_ 1 1 Intel(R) 31 34.7 2.5

v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
Standard_D3_ 4 1 Intel(R) 27 133.4 9,1

v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
TASA BASE
Standard_D4_ 8 1 Intel(R) 15 238,7 4.4.

v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Standard_D5_ 16 1 Intel(R) 9 413,9 14,1

v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
TASA BASE

_v2 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

_v2 Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
Esv3: optimizada para memoria y almacenamiento Premium

TASA BASE
Standard_E2s_ 2 1 Intel(R) 39 42,5 2.2

v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Standard_E4s_ 4 1 Intel(R) 28 81,4 3.3

v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Standard_E8s_ 8 1 Intel(R) 29 156,3 5,1

v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Standard_E8- 2 1 Intel(R) 57 41,8 2.6

2s_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

4s_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Standard_E16 16 1 Intel(R) 31 295,7 4.5.

s_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Standard_E16 4 1 Intel(R) 45 82,7 3.8

-4s_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
TASA BASE

-8s_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

s_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Standard_E32 32 2 Intel(R) 31 577,9 9,4

s_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

-8s_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

-16s_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

2s_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

s_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

-16s_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

-32s_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Eisv3: optimizada para memoria y Premium Storage (aislado)

TASA BASE
Standard_E64i 64 2 Intel(R) 28 1073,9 5.7

s_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Ev3: optimizada para memoria
TASA BASE
Standard_E2_ 2 1 Intel(R) 41 41,2 2.4

v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Eiv3: optimizada para memoria (aislado)

TASA BASE
Standard_E64i 64 2 Intel(R) 28 1081,4 11,1

_v3 Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Fsv2: proceso y optimizada para almacenamiento

TASA BASE
TASA BASE
Standard_F2s_ 2 1 Intel(R) 46 56,5 2.4

v2 Xeon(R)
Platinum
8168 CPU a
2,70 GHz
Standard_F4s_ 4 1 Intel(R) 60 110,2 4,7

v2 Xeon(R)
Platinum
8168 CPU a
2,70 GHz
Standard_F8s_ 8 1 Intel(R) 36 215,2 5.3

v2 Xeon(R)
Platinum
8168 CPU a
2,70 GHz
Standard_F16 16 1 Intel(R) 36 409,3 15,5

s_v2 Xeon(R)
Platinum
8168 CPU a
2,70 GHz

s_v2 Xeon(R)
Platinum
8168 CPU a
2,70 GHz

s_v2 Xeon(R)
Platinum
8168 CPU a
2,70 GHz

s_v2 Xeon(R)
Platinum
8168 CPU a
2,70 GHz
Fs: proceso y optimizada para almacenamiento

TASA BASE
Standard_F1s 1 1 Intel(R) 31 33,2 1.0

Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
TASA BASE

Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
Standard_F4s 4 1 Intel(R) 25 127,7 4.5.

Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
Standard_F8s 8 1 Intel(R) 19 251,2 4.5.

Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
Standard_F16 16 1 Intel(R) 9 413,9 3.6

s Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

s Xeon(R) CPU
E5-2673 v4 a
2,30 GHz
F: optimizada para proceso

TASA BASE

Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
TASA BASE

Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

Xeon(R) CPU
E5-2673 v3 a
2,40 GHz

Xeon(R) CPU
E5-2673 v4 a
2,30 GHz

Xeon(R) CPU
E5-2673 v3 a
2,40 GHz
GS: optimizada para almacenamiento

TASA BASE
Standard_GS1 2 1 Intel(R) 29 63,6 4,7

Xeon(R) CPU
E5-2698B v3
a 2,00 GHz
Standard_GS2 4 1 Intel(R) 29 122,3 6.9

Xeon(R) CPU
E5-2698B v3
a 2,00 GHz

Xeon(R) CPU
E5-2698B v3
a 2,00 GHz
Standard_GS4 16 1 Intel(R) 31 391,4 28,6

Xeon(R) CPU
E5-2698B v3
a 2,00 GHz

-4 Xeon(R) CPU
E5-2698B v3
a 2,00 GHz

-8 Xeon(R) CPU
E5-2698B v3
a 2,00 GHz

Xeon(R) CPU
E5-2698B v3
a 2,00 GHz

-8 Xeon(R) CPU
E5-2698B v3
a 2,00 GHz

-16 Xeon(R) CPU
E5-2698B v3
a 2,00 GHz
G: optimizada para proceso

TASA BASE
Standard_G1 2 1 Intel(R) 29 64,7 9.2

Xeon(R) CPU
E5-2698B v3
a 2,00 GHz
TASA BASE
Standard_G2 4 1 Intel(R) 30 127,9 12,2

Xeon(R) CPU
E5-2698B v3
a 2,00 GHz

Xeon(R) CPU
E5-2698B v3
a 2,00 GHz
Standard_G4 16 1 Intel(R) 31 400,2 3.9

Xeon(R) CPU
E5-2698B v3
a 2,00 GHz

Xeon(R) CPU
E5-2698B v3
a 2,00 GHz
H: Proceso de alto rendimiento (HPC)

TASA BASE
Standard_H8 8 1 Intel(R) 31 296,1 1.4

Xeon(R) CPU
E5-2667 v3 a
3,20 GHz

m Xeon(R) CPU
E5-2667 v3 a
3,20 GHz

Xeon(R) CPU
E5-2667 v3 a
3,20 GHz

m Xeon(R) CPU
E5-2667 v3 a
3,20 GHz

mr Xeon(R) CPU
E5-2667 v3 a
3,20 GHz
Standard_H16 16 2 Intel(R) 17 562,2 4,2

r Xeon(R) CPU
E5-2667 v3 a
3,20 GHz
Ls: optimizada para almacenamiento
TASA BASE
Standard_L4s 4 1 Intel(R) 29 122,7 6.6

Xeon(R) CPU
E5-2698B v3
a 2,00 GHz
Standard_L8s 8 1 Intel(R) 30 223,3 7.5

Xeon(R) CPU
E5-2698B v3
a 2,00 GHz
Standard_L16 16 1 Intel(R) 31 397,3 2.5

s Xeon(R) CPU
E5-2698B v3
a 2,00 GHz
Standard_L32 32 2 Intel(R) 31 766,1 3,5

s Xeon(R) CPU
E5-2698B v3
a 2,00 GHz
M: optimizada para memoria

TASA BASE
Standard_M8- 2 1 Intel(R) 15 42.1 2.1

2ms Xeon(R) CPU
E7-8890 v3 a
2,50 GHz
Standard_M8- 4 1 Intel(R) 13 81.6 2.9

4ms Xeon(R) CPU
E7-8890 v3 a
2,50 GHz
Standard_M1 4 1 Intel(R) 14 82,5 2.5

6-4ms Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

6-8ms Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

2-8ms Xeon(R) CPU
E7-8890 v3 a
2,50 GHz
TASA BASE
Standard_M3 16 1 Intel(R) 12 306,5 0,5

2-16ms Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

4 Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

4-16ms Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

4-32ms Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

4m Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

4ms Xeon(R) CPU
E7-8890 v3 a
2,50 GHz
Standard_M6 64 2 Intel(R) 12 1012,5 4.5.

4s Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

28 Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

28-32ms Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

28-64ms Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

28m Xeon(R) CPU
E7-8890 v3 a
2,50 GHz
TASA BASE

28ms Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

28s Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

6ms Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

2ls Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

2ms Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

2ms Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

2ts Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

4ls Xeon(R) CPU
E7-8890 v3 a
2,50 GHz

ms Xeon(R) CPU
E7-8890 v3 a
2,50 GHz
NCSv3: habilitada para GPU

TASA BASE
Standard_NC6 6 1 Intel(R) 6 230,2 1.6

s_v3 Xeon(R) CPU
E5-2690 v4 a
2,60 GHz
TASA BASE

2s_v3 Xeon(R) CPU
E5-2690 v4 a
2,60 GHz
Standard_NC2 24 2 Intel(R) 2 811,0 4,2

4rs_v3 Xeon(R) CPU
E5-2690 v4 a
2,60 GHz

4s_v3 Xeon(R) CPU
E5-2690 v4 a
2,60 GHz
NCSv2: habilitada para GPU

TASA BASE

s_v2 Xeon(R) CPU
E5-2690 v4 a
2,60 GHz

2s_v2 Xeon(R) CPU
E5-2690 v4 a
2,60 GHz

4rs_v2 Xeon(R) CPU
E5-2690 v4 a
2,60 GHz
Standard_NC2 24 2 Intel(R) 11 811,5 4.4.

4s_v2 Xeon(R) CPU
E5-2690 v4 a
2,60 GHz
NC: habilitada para GPU

TASA BASE
Standard_NC6 6 1 Intel(R) 27 209,6 4.4.

Xeon(R) CPU
E5-2690 v3 a
2,60 GHz

2 Xeon(R) CPU
E5-2690 v3 a
2,60 GHz
TASA BASE
Standard_NC2 24 2 Intel(R) 28 751,7 3,5

4 Xeon(R) CPU
E5-2690 v3 a
2,60 GHz

4r Xeon(R) CPU
E5-2690 v3 a
2,60 GHz
NDs: habilitada para GPU

TASA BASE
Standard_ND 6 1 Intel(R) 8 230,1 1.2

6s Xeon(R) CPU
E5-2690 v4 a
2,60 GHz
Standard_ND 12 1 Intel(R) 11 426,5 1.4

12s Xeon(R) CPU
E5-2690 v4 a
2,60 GHz
Standard_ND 24 2 Intel(R) 10 811,4 3,5

24rs Xeon(R) CPU
E5-2690 v4 a
2,60 GHz
Standard_ND 24 2 Intel(R) 11 812,6 4.4.

24s Xeon(R) CPU
E5-2690 v4 a
2,60 GHz
NV: habilitada para GPU

TASA BASE
Standard_NV6 6 1 Intel(R) 28 210,5 6.1

Xeon(R) CPU
E5-2690 v3 a
2,60 GHz
Standard_NV1 12 1 Intel(R) 28 394,5 2.3

2 Xeon(R) CPU
E5-2690 v3 a
2,60 GHz
Standard_NV2 24 2 Intel(R) 26 752,2 4.4.

4 Xeon(R) CPU
E5-2690 v3 a
2,60 GHz
Acerca de SPECint
Las cifras de Windows se calcularon mediante la ejecución de SPECint 2006 en Windows Server. SPECint se
ejecutó con la opción de tasa base (SPECint_rate2006), con una copia por vCPU. SPECint consta de 12 pruebas
independientes y cada una se ejecuta tres veces, tomando el valor medio de cada prueba y ponderándolo para
formar una puntuación compuesta. Se muestran las pruebas que se ejecutaron en varias máquinas virtuales para
proporcionar las puntuaciones promedio.
Pasos siguientes
Para más información sobre las capacidades de almacenamiento, los detalles del disco y consideraciones
adicionales para seleccionar tamaños de máquinas virtuales, consulte Tamaños de máquinas virtuales.
Cuotas de vCPU de máquinas virtuales
Las cuotas de vCPU para máquinas virtuales y conjuntos de escalado de máquinas virtuales se organizan en dos
niveles para cada suscripción en cada región. El primer nivel es el número de vCPU regionales totales y el segundo
son los núcleos de las diversas familias de tamaños de máquina virtual, como las vCPU de la serie D estándar.
Siempre que se implemente una máquina virtual nueva, las vCPU de dicha máquina virtual no deben exceder la
cuota de vCPU de la familia de tamaños de máquina virtual o el total de la cuota de vCPU regional. Si se supera
cualquiera de esas dos cuotas, no se permitirá la implementación de la máquina virtual. También hay una cuota
para el número total de máquinas virtuales en la región. Se pueden ver los detalles de cada una de estas cuotas en
la sección Uso y cuotas de la página Suscripción en Azure Portal, o bien puede consultar los valores mediante
PowerShell.
Comprobación del uso

Puede usar el cmdlet Get-AzVMUsage para comprobar el uso de la cuota.
Get-AzVMUsage -Location "East US"
El resultado será similar al siguiente:

Name Current Value Limit Unit
---- ------------- ----- ----
Availability Sets 0 2000 Count
Total Regional vCPUs 4 260 Count
Virtual Machines 4 10000 Count
Virtual Machine Scale Sets 1 2000 Count
Standard B Family vCPUs 1 10 Count
Standard DSv2 Family vCPUs 1 100 Count
Standard Dv2 Family vCPUs 2 100 Count
Basic A Family vCPUs 0 100 Count
Standard A0-A7 Family vCPUs 0 250 Count
Standard A8-A11 Family vCPUs 0 100 Count
Standard D Family vCPUs 0 100 Count
Standard G Family vCPUs 0 100 Count
Standard DS Family vCPUs 0 100 Count
Standard GS Family vCPUs 0 100 Count
Standard F Family vCPUs 0 100 Count
Standard FS Family vCPUs 0 100 Count
Standard NV Family vCPUs 0 24 Count
Standard NC Family vCPUs 0 48 Count
Standard H Family vCPUs 0 8 Count
Standard Av2 Family vCPUs 0 100 Count
Standard LS Family vCPUs 0 100 Count
Standard Dv2 Promo Family vCPUs 0 100 Count
Standard DSv2 Promo Family vCPUs 0 100 Count
Standard MS Family vCPUs 0 0 Count
Standard Dv3 Family vCPUs 0 100 Count
Standard DSv3 Family vCPUs 0 100 Count
Standard Ev3 Family vCPUs 0 100 Count
Standard ESv3 Family vCPUs 0 100 Count
Standard FSv2 Family vCPUs 0 100 Count
Standard ND Family vCPUs 0 0 Count
Standard NCv2 Family vCPUs 0 0 Count
Standard NCv3 Family vCPUs 0 0 Count
Standard LSv2 Family vCPUs 0 0 Count
Standard Storage Managed Disks 2 10000 Count
Premium Storage Managed Disks 1 10000 Count
Instancias reservadas de máquina virtual

Las instancias reservadas de máquina virtual, cuyo ámbito es una sola suscripción sin tamaño de máquina virtual
flexible, agregarán un aspecto nuevo a las cuotas de vCPU. Estos valores describen el número de instancias del
tamaño indicado que deben poderse implementar en la suscripción. Actúan como un marcador de posición en el
sistema de cuotas para asegurarse de que esa cuota esté reservada y que las instancias reservadas de máquina
virtual puedan implementarse en la suscripción. Por ejemplo, si una suscripción específica tiene diez instancias
reservadas de máquina virtual Standard_D1, el límite de uso para las instancias reservadas de máquina virtual
Standard_D1 será de diez. Esto hará que Azure se asegure de que siempre hay al menos 10 vCPU disponibles en el
total de la cuota de vCPU regional que se utilizará para instancias de Standard_D1 y que hay al menos 10 vCPU
disponibles en la cuota de vCPU de la Familia D estándar que se utilizará para las instancias de Standard_D1.
Si es necesario un incremento de cuota para adquirir una instancia reservada de suscripción única, puede
solicitarlo en su suscripción.
Pasos siguientes
Para obtener más información sobre facturación y cuotas, consulte Límites, cuotas y restricciones de suscripción y
servicios de Microsoft Azure.
Ahorro de costos con Azure Reserved VM Instances
Cuando haga "commit" a una instancia reservada de VM de Azure, puede ahorrar dinero. El descuento de la
reserva se aplica automáticamente el número de máquinas virtuales en ejecución que coincidan con el ámbito y los
atributos de la reserva. No es necesario asignar una reserva a una máquina virtual para obtener los descuentos.
Una compra de instancia reservada cubre solo la parte de proceso del uso de la máquina virtual. En el caso de las
máquinas virtuales Windows, el medidor de uso se divide en dos medidores independientes. Hay un medidor de
proceso, que es el mismo que el medidor de Linux, y un medidor de IP de Windows. Los cargos que verá al hacer
la compra son solo por los costos de proceso. Los cargos no incluyen los costos de software de Windows. Para
obtener más información sobre los costos de software, consulte los costos de software no incluidos en Azure
Reserved Virtual Machine Instances.
Determinación del tamaño adecuado de una máquina virtual antes de

su adquisición
Antes de adquirir una reserva, debe determinar el tamaño de la máquina virtual que necesita. Las siguientes
secciones le ayudarán a determinar el tamaño correcto de la máquina virtual.
Usar recomendaciones de reserva
Puede consultar las recomendaciones de reserva para averiguar las reservas que debe adquirir.
Se mostrarán recomendaciones de compra y la cantidad recomendada al adquirir una instancia reservada de
máquina virtual en Azure Portal.
Azure Advisor proporciona recomendaciones de compra de suscripciones individuales.
Puede usar las API para obtener recomendaciones de compra relativas tanto a los ámbitos de suscripción tanto
compartida como única. Para más información, vea Recommendations API de compra de instancia reservada
para clientes empresariales.
En el caso de los clientes de Contrato Enterprise (EA) y del Contrato de cliente de Microsoft (MCA), las
recomendaciones de compra de los ámbitos de suscripción tanto única como compartida solo están disponibles
con el paquete de contenido de Power BI de Azure Consumption Insights.
Servicios que obtienen descuentos de reserva de máquina virtual
Puede aplicar sus reservas de máquina virtual al uso de máquinas virtuales emitidas desde varios servicios, no
solo a sus implementaciones de máquinas virtuales. Los recursos que obtienen descuentos de reserva cambian en
función de la configuración de flexibilidad de tamaño de instancia.
Configuración de flexibilidad de tamaño de instancia
La configuración de flexibilidad de tamaño de instancia determina qué servicios obtienen los descuentos de la
instancia reservada.
Tanto si la configuración está activada como si no, los descuentos de reserva se aplican automáticamente a
cualquier uso de máquina virtual que coincida cuando ConsumedService sea Microsoft.Compute . Por lo tanto,
compruebe los datos de uso del valor ConsumedService. Estos son algunos ejemplos:
Máquinas virtuales
Servicio de contenedor
Implementaciones de Azure Batch (en modo de suscripciones de usuario)
Azure Kubernetes Service (AKS )
Service Fabric
Cuando la configuración está activada, los descuentos de reserva se aplican automáticamente al uso de máquina
virtual que coincida cuando ConsumedService sea alguno de los elementos siguientes:
Microsoft.Compute
Microsoft.ClassicCompute
Microsoft.Batch
Microsoft.MachineLearningServices
Microsoft.Kusto
Compruebe el valor ConsumedService en los datos de uso para determinar si el uso puede optar a los descuentos
de reserva.
Para obtener más información sobre la flexibilidad de tamaño de instancia, vea Flexibilidad en el tamaño de las
máquinas virtuales con Azure Reserved VM Instances.
Analizar la información de uso
Analice su información de uso para averiguar qué reservas debe adquirir.
Los datos de uso están disponibles en el archivo de uso y en las API. Úselos de manera conjunta para determinar
qué reserva adquirir. Para determinar la cantidad de reservas que necesita adquirir, compruebe si hay instancias de
máquina virtual que tengan un uso elevado diario.
No tenga en cuenta la subcategoría Meter ni los campos Product de los datos de uso, ya que no distinguen los
distintos tamaños de máquina virtual que usan Premium Storage. Si usa estos campos para determinar el tamaño
de máquina virtual al adquirir la reserva, puede correr el riesgo de adquirir un tamaño equivocado, y no obtendrá
el descuento de reserva que espera. En su lugar, consulte el campo AdditionalInfo del archivo o la API de uso
para determinar el tamaño apropiado de la máquina virtual.
Consideraciones sobre restricciones de compra
Las instancias reservadas de máquinas virtuales están disponibles para la mayoría de los tamaños de máquina
virtual, a excepción de los indicados aquí. El descuento de la reserva no se aplica en las siguientes máquinas
virtuales:
Series de máquinas virtuales: serie A, serie Av2 o serie G.
Máquinas virtuales de versión preliminar o promocionales: cualquier serie o tamaño de máquina
virtual que se encuentra en versión preliminar o usa el medidor promocional.
Nubes: las reservas no están disponibles para la compra en las regiones de Alemania o China.
Cuota insuficiente: una reserva cuyo ámbito sea de una sola suscripción debe tener cuota de vCPU
disponible en la suscripción para la nueva instancia reservada. Por ejemplo, si la suscripción de destino tiene
un límite de cuota de 10 vCPU para la serie D, no podrá comprar una reserva para 11 instancias
Standard_D1. La comprobación de cuota para las reservas incluye las máquinas virtuales ya implementadas
en la suscripción. Por ejemplo, si la suscripción tiene una cuota de 10 vCPU para la serie D y tiene
implementadas dos instancias standard_D1, podrá comprar una reserva para 10 instancias standard_D1 en
esta suscripción. También puede cursar una solicitud de aumento de la cuota para resolver este problema.
Restricciones de capacidad: en algunas circunstancias poco frecuentes, Azure limita la compra de nuevas
reservas a un subconjunto de tamaños de máquina virtual debido a que la capacidad en una región es baja.
Compra de una instancia reservada de máquina virtual

Puede comprar una instancia reservada de máquina virtual en Azure Portal. Pague la reserva por adelantado o
mensualmente.
Estos requisitos se aplican a la compra de una instancia reservada de máquina virtual:
Debe tener un rol de propietario en al menos una suscripción de EA o en una suscripción con una tarifa de pago
por uso.
En el caso de las suscripciones de EA, la opción Agregar instancias reservadas debe estar habilitada en el
portal de EA. O bien, si esa opción está deshabilitada, debe ser un administrador de EA en la suscripción.
En el caso del programa Proveedor de soluciones en la nube (CSP ), solo los agentes de administración o de
ventas pueden adquirir reservas.
Para comprar una instancia:
2. Seleccione Todos los servicios > Reservations.
3. Seleccione Agregar para comprar una nueva reserva y, luego, haga clic en Máquina virtual.
4. Rellene los campos obligatorios. Las instancias de máquina virtual en ejecución que coinciden con los atributos
seleccionados cumplen los requisitos para obtener el descuento de la reserva. El número real de las instancias
de máquina virtual que obtienen el descuento depende el ámbito y la cantidad seleccionada.
CAMPO DESCRIPCIÓN
Subscription Suscripción que se usa para pagar la reserva. Los costos de la

reserva se cobran en el método de pago de la suscripción. El
tipo de suscripción debe ser Contrato Enterprise (números de
oferta: MS-AZR-0017P o MS-AZR-0148P) o Contrato de
cliente de Microsoft o una suscripción individual con tarifas de
pago por uso (números de oferta: MS-AZR-0003P o MS-AZR-
0023P). Los cargos se deducen del saldo de compromiso
monetario, si está disponible, o se cobran como uso por
encima del límite. En una suscripción con tarifas de pago por
uso, los cargos se cobran con el método de pago de factura o
la tarjeta de crédito de la suscripción.
Ámbito El ámbito de la reserva puede cubrir una o varias suscripciones

(ámbito compartido). Si selecciona:
Single resource group scope (Ámbito de grupo de
recursos único): aplica el descuento por reserva a los
recursos coincidentes solo en el grupo de recursos
seleccionado.
Single subscription scope (Ámbito de suscripción
única): aplica el descuento por reserva a los recursos
coincidentes de la suscripción seleccionada.
Ámbito compartido: aplica el descuento por reserva
a los recursos coincidentes en suscripciones aptas que
están en el contexto de facturación. Para los clientes de
EA, el contexto de facturación es la inscripción. En el
caso de suscripciones individuales con tarifas de pago
por uso, el ámbito de facturación son todas las
suscripciones aptas creadas por el administrador de la
cuenta.
Region Región de Azure que está cubierta por la reserva.
Tamaño de VM Tamaño de las instancias de máquina virtual.

CAMPO DESCRIPCIÓN
Optimizar para La flexibilidad de tamaño de instancia de máquina virtual está

seleccionada de forma predeterminada. Haga clic en
Configuración avanzada para cambiar el valor de flexibilidad
de tamaño de instancia, con el fin de aplicar el descuento de
reserva a otras VM del mismo grupo de tamaño de VM. La
prioridad de capacidad da preferencia a la capacidad del centro
de datos para las implementaciones. Esto ofrece una mayor
confianza en su capacidad para iniciar instancias de máquinas
virtuales cuando las necesite. La prioridad de capacidad solo
está disponible si el ámbito de la reserva es de suscripción
única.
Término Un año o tres años.
Cantidad Número de instancias que se compran dentro de la reserva. La

cantidad es el número de instancias de máquina virtual en
ejecución a las que se aplica el descuento de facturación. Por
ejemplo, si ejecuta 10 máquinas virtuales Standard_D2 en la
región Este de EE. UU., debería especificar 10 como cantidad
para maximizar el beneficio de todas las máquinas virtuales en
ejecución.
Datos de uso y utilización de la reserva

Los datos de uso que obtienen un descuento de reserva tienen un precio efectivo de cero. Puede ver qué instancia
de máquina virtual recibió el descuento de reserva para cada reserva.
Para obtener más información sobre cómo aparecen los descuentos de reserva en los datos de uso, consulte
Obtención del uso y los costos de reservas de Contrato Enterprise si es un cliente de EA. Si tiene una suscripción
individual, consulte Descripción del uso de reservas para su suscripción individual de pago por uso.
Cambiar una reserva después de la compra

Puede realizar los siguientes tipos de cambios en una reserva después de haberla comprado:
Actualización del ámbito de la reserva
Flexibilidad del tamaño de instancia (si procede)
Propiedad
También puede dividir una reserva en fragmentos más pequeños y combinar reservas ya divididas. Ninguno de
estos cambios conlleva una nueva transacción comercial ni un cambio en la fecha de finalización de la reserva.
No se pueden realizar los siguientes tipos de cambios tras la compra:
La región de una reserva existente
SKU
Cantidad
Duration
Pero sí se puede intercambiar una reserva si quiere realizar cambios.
Cancelación, intercambio o reembolso de reservas

Puede cancelar, intercambiar o reembolsar reservas con ciertas limitaciones. Para obtener más información,
consulte Autoservicio de intercambios y reembolsos de reservas de Azure.
¿Necesita ayuda? Póngase en contacto con nosotros.

Si tiene alguna pregunta o necesita ayuda, cree una solicitud de soporte técnico.
Pasos siguientes
Para más información sobre cómo administrar una reserva, consulte Administración de Azure Reservations.
Para obtener más información acerca de Azure Reservations, consulte los siguientes artículos:
¿Qué es Azure Reservations?
Administración de reservas en Azure
Información sobre cómo se aplica el descuento por la reserva
Información sobre el uso de reservas de Azure para suscripciones de pago por uso
Información sobre el uso de reservas para la inscripción Enterprise
Costos de software de Windows no incluidos con reservas
Azure Reservations en el programa del Proveedor de soluciones en la nube (CSP ) del Centro de partners
¿Qué es Azure Reservations?
Con Azure Reservations ahorrará gastos al confirmar los planes de un año o tres para las máquinas virtuales, la
capacidad de proceso de SQL Database, Azure Blob Storage o Azure Data Lake Storage Gen2, el rendimiento de
Azure Cosmos DB u otros recursos de Azure. La confirmación le permite obtener un descuento en los recursos
que utiliza. Reservations puede reducir significativamente los costos de los recursos hasta un 72 % en los precios
de pago por uso. Reservations ofrece un descuento en la facturación y no afecta al estado del entorno de ejecución
de los recursos.
Puede pagar una reserva por adelantado o mensualmente. El costo total de las reservas por adelantado y
mensuales es el mismo y no se pagan cargos adicionales por elegir el pago mensual. El pago mensual está
disponible para las reservas de Azure, no para los productos de terceros.
Puede comprar una reserva en Azure Portal.
¿Por qué comprar una reserva?

Si tiene máquinas virtuales, datos de Blob Storage, bases de datos SQL o Azure Cosmos DB que usen una
capacidad o una cantidad de procesos significativas, o bien se ejecuten durante largos períodos, la compra de una
reserva le proporcionará la opción más rentable. Por ejemplo, si ejecuta continuamente cuatro instancias de un
servicio sin una reserva, se le cobra según las tarifas de pago por uso. Cuando compre una reserva para esos
recursos, obtendrá inmediatamente el descuento por reserva. Ya no se aplicarán a los recursos las tarifas de pago
por uso.
Cargos cubiertos por la reserva

Planes de servicio:
Instancia reservada de máquina virtual: una reserva solo cubre el costo de proceso de máquina virtual. No
cubre cargos por software adicional, administración de redes ni almacenamiento.
Capacidad reservada de Azure Storage: una reserva cubre la capacidad de almacenamiento de las cuentas
de almacenamiento estándar para el almacenamiento de blobs o el almacenamiento de Azure Data Lake Gen2.
La reserva no cubre las tasas de ancho de banda o de transacción.
Capacidad reservada de Azure Cosmos DB: una reserva abarca el rendimiento aprovisionado de los
recursos. No cubre los cargos de almacenamiento y redes.
Núcleo virtual reservado de SQL Database: solo se incluyen con una reserva los costos de proceso. La
licencia se factura por separado.
SQL Data Warehouse: una reserva cubre el uso de cDWU. No cubre los cargos de almacenamiento o de red
asociados con el uso de SQL Data Warehouse.
Impuesto sobre el timbre de App Service: una reserva cubre el uso del timbre. No se aplica a los trabajos,
por lo que los demás recursos asociados con el timbre se cobran por separado.
Para las máquinas virtuales de Windows y SQL Database, puede cubrir los costos de licencia de Windows con la
Ventaja híbrida de Azure.
¿Quién puede comprar una reserva?

Para comprar un plan, debe tener un rol de propietario de la suscripción en una suscripción Enterprise (MS -AZR -
0017P o MS -AZR -0148P ) o de pago por uso (MS -AZR -0003P o MS -AZR -0023P ), o bien una suscripción de
Microsoft Customer Agreement. Los proveedores de soluciones en la nube pueden usar Azure Portal o el Centro
de partnerspara comprar reservas de Azure.
Los clientes de Contrato Enterprise (EA) pueden limitar sus compras a los administradores de EA mediante la
desactivación de la opción Add Reserved Instances (Agregar instancias reservadas) en EA Portal. Para poder
comprar una reserva, los administradores de Contrato Enterprise deben ser propietarios de la suscripción para al
menos una suscripción de Contrato Enterprise. La opción es útil para empresas que requieren un equipo
centralizado para comprar reservas para distintos centros de coste. Después de la compra, los equipos
centralizados pueden agregar propietarios de centros de coste a las reservas. Los propietarios pueden entonces
ampliar la reserva a sus suscripciones. El equipo central no necesita tener acceso al propietario de la suscripción
donde se compra la reserva.
Los descuentos por reserva se aplican solo a los recursos asociados con las suscripciones compradas a través de
un contrato Enterprise, Proveedor de soluciones en la nube (CSP ), Microsoft Customer Agreement y de planes
individuales con tarifas de pago por uso.
Ámbito de las reservas

Puede limitar el ámbito de una reserva a una suscripción o a grupos de recursos. Al limitar el ámbito de una
reserva, se selecciona el lugar en el que se aplican los ahorros de la reserva. Al limitar el ámbito de la reserva a un
grupo de recursos, los descuentos por reserva solo se aplican al grupo de recursos, no a la suscripción completa.
Opciones de limitación del ámbito de la reserva
Con la limitación del ámbito del grupo de recursos tiene tres opciones para limitar el ámbito de una reserva, según
sus necesidades:
Single resource group scope (Ámbito de grupo de recursos único): aplica el descuento por reserva a los
recursos coincidentes solo en el grupo de recursos seleccionado.
Single subscription scope (Ámbito de suscripción única): aplica el descuento por reserva a los recursos
coincidentes de la suscripción seleccionada.
Ámbito compartido: aplica el descuento por reserva a los recursos coincidentes en suscripciones aptas que
están en el contexto de facturación. Para los clientes con Contrato Enterprise, el contexto de facturación es la
inscripción. En el caso de los clientes con contrato Microsoft Customer Agreement, el ámbito de facturación es
el perfil de facturación. En el caso de suscripciones individuales con tarifas de pago por uso, el ámbito de
facturación son todas las suscripciones aptas creadas por el administrador de la cuenta.
Al aplicar los descuentos por reserva sobre su uso, Azure procesa la reserva en el orden siguiente:
1. Reservas cuyo ámbito es un grupo de recursos
2. Reservas de ámbito único
3. Reservas de ámbito compartido
Un único grupo de recursos puede obtener descuentos por reserva de varias reservas, en función de cómo se
establezca el ámbito de las reservas.
Limitación del ámbito de una reserva a un grupo de recursos
Puede limitar el ámbito de la reserva a un grupo de recursos al comprar la reserva o bien hacerlo después. Para
limitar el ámbito de la reserva a un grupo de recursos, debe ser el propietario de la suscripción.
Para establecer el ámbito, vaya a la página Comprar reservas en Azure Portal. Seleccione el tipo de reserva que
quiere comprar. En el formulario de selección Seleccione el producto que quiere comprar, cambie el valor de
Ámbito a Grupo de recursos único. Después, seleccione un grupo de recursos.
Se muestran las recomendaciones de compra del grupo de recursos en la reserva de máquina virtual. Las
recomendaciones se calculan mediante el análisis del uso durante los últimos 30 días. Si el costo de la ejecución de
recursos con instancias reservadas es más barato que el costo de la ejecución de recursos con tarifas de pago por
uso, se realiza una recomendación de compra. Para más información sobre las recomendaciones de compra de
reservas, consulte la entrada de blog Get Reserved Instance purchase recommendations based on usage pattern
(Obtener recomendaciones de compra de instancias reservadas basadas en el patrón de uso).
También puede actualizar el ámbito después de comprar una reserva. Para ello, vaya a la reserva, haga clic en
Configuración y limite de nuevo el ámbito de la reserva. Volver a limitar el ámbito de una reserva no es una
transacción comercial. No se cambian las condiciones de la reserva. Para más información sobre cómo actualizar el
ámbito, consulte Update the scope after you purchase a reservation (Actualización del ámbito después de comprar
una reserva).
Supervisión y optimización del uso de reservas

Puede supervisar el uso de la reserva de varias maneras: mediante Azure Portal, las API o los datos de uso. Para
ver todas las reservas a las que tiene acceso, vaya a Reservas en Azure Portal. La cuadrícula de reservas muestra
el último porcentaje de uso registrado para la reserva. Haga clic en la reserva para ver su uso a largo plazo.
También puede obtener el uso de la reserva mediante las API y a partir de los datos de uso si es un cliente con
contrato Enterprise o con contrato Microsoft Customer Agreement.
Si observa que el uso de la reserva con ámbito de grupo de recursos es bajo, puede actualizar el ámbito de la
reserva a una suscripción única o compartirlo en el contexto de facturación. También puede dividir la reserva y
aplicar las reservas resultantes a distintos grupos de recursos.
Otras consideraciones
Si no tiene recursos que coincidan en un grupo de recursos, la reserva estará infrautilizada. La reserva no se aplica
automáticamente a un grupo de recursos o una suscripción diferentes en los que haya un uso bajo.
Un ámbito de reserva no se actualiza automáticamente si se mueve el grupo de recursos de una suscripción a otra.
El ámbito no se actualiza si se elimina el grupo de recursos. Tendrá que volver a limitar el ámbito de la reserva. Si
no, la reserva estará infrautilizada.
Tipos de ofertas y suscripciones con descuento

Los descuentos por reserva se aplican a las siguientes suscripciones aptas y tipos de ofertas.
Contrato Enterprise (números de oferta: MS -AZR -0017P o MS -AZR -0148P )
Suscripciones del contrato Microsoft Customer Agreement.
Planes individuales con tarifas de pago por uso (números de oferta: MS -AZR -0003P o MS -AZR -0023P )
Suscripciones de CSP
Los recursos que se ejecutan en una suscripción con otros tipos de oferta no recibirán el descuento por la reserva.
¿Cómo se factura una reserva?

La reserva se cobra en el método de pago vinculado a la suscripción. El costo de la reserva se deducirá del saldo
del compromiso monetario, si está disponible. Cuando este no sea suficiente para cubrir el costo de la reserva, se
le cobrará el monto restante. Si tiene una suscripción de un plan individual con tarifas de pago por uso, se factura
inmediatamente en la tarjeta de crédito que tiene en su cuenta por las compras por adelantado. Los pagos
mensuales aparecen en la factura y la tarjeta de crédito se cobra mensualmente. Cuando se le facture por factura,
verá los cargos la próxima vez que reciba una.
Aplicación del descuento por reserva

El descuento por reserva se aplica a la utilización de recursos que coincide con los atributos seleccionados al
comprar la reserva. Los atributos incluyen el ámbito en el que se ejecutan las máquinas virtuales, SQL Database,
Azure Cosmos DB u otras ejecuciones de recursos. Por ejemplo, si quiere un descuento por reserva para las cuatro
máquinas virtuales Estándar D2 en la región Oeste de EE. UU., seleccione la suscripción en la que se ejecutan las
Un descuento de reserva significa "usarlo o perderlo". Si no tiene recursos coincidentes para ninguna hora,
perderá una cantidad de reserva para esa hora. No se pueden arrastrar las horas reservadas no utilizadas.
Al cerrar un recurso, el descuento por reserva se aplica automáticamente a otro recurso que coincida con el ámbito
especificado. Si no se encuentran recursos coincidentes en el ámbito especificado, entonces las horas reservadas se
pierden.
Por ejemplo, más adelante podría crear un recurso y tener una reserva que coincida con la que está infrautilizada.
El descuento por reserva se aplica automáticamente al nuevo recurso coincidente.
Si, por el contrario, sus máquinas virtuales se ejecutan en diferentes suscripciones dentro de su cuenta o
inscripción, seleccione el ámbito compartido. El ámbito compartido le permite aplicar el descuento de la reserva en
varias suscripciones. También puede cambiar el ámbito después de la compra de la reserva. Para más información,
consulte Administración de Azure Reservations.
Los descuentos por reserva solo se aplican a los recursos asociados con Enterprise, Microsoft Customer
Agreement, CSP o a las suscripciones con tarifas de pago por uso. Los recursos que se ejecutan en una suscripción
con otros tipos de oferta no recibirán el descuento por la reserva.
Cuando expira el plazo de reserva

Al final del plazo de reserva, el descuento de facturación expira y los recursos se facturan según los precios de
pago por uso. De forma predeterminada, las reservas no se establecen para renovarse automáticamente. Puede
optar por habilitar la renovación automática de una reserva mediante la selección de la opción de la configuración
de renovación. Con la renovación automática, se comprará una reserva de reemplazo cuando expire la reserva
existente. De forma predeterminada, la reserva de reemplazo tiene los mismos atributos que la reserva que expira
y, opcionalmente, puede cambiar la frecuencia de facturación, el plazo o la cantidad en la configuración de
renovación. Cualquier usuario con acceso de propietario en la reserva y la suscripción que se usa para la
facturación puede configurar la renovación.
El descuento se aplica a los diferentes tamaños

Al comprar una reserva, puede aplicar el descuento a otras instancias con atributos que están dentro del mismo
grupo de tamaño. Esta característica se conoce como flexibilidad de tamaño de instancia. La flexibilidad de la
cobertura del descuento depende del tipo de reserva y los atributos que elija al comprar la reserva.
Planes de servicio:
Instancias reservadas de máquina virtual: al comprar la reserva y seleccionar Optimizado para: flexibilidad
de tamaño de instancia, la cobertura de descuento dependerá del tamaño de máquina virtual que elija. La
reserva se puede aplicar a los tamaños de máquinas virtuales (VM ) en el mismo grupo de series de tamaño. Si
quiere saber más, vea Flexibilidad en el tamaño de las máquinas virtuales con Azure Reserved VM Instances.
Capacidad reservada de Azure Storage: puede adquirir capacidad reservada para cuentas de Azure Storage
estándar en unidades de 100 TiB o de 1 PiB al mes. La capacidad reservada de Azure Storage está disponible
en todas las regiones para cualquier nivel de acceso (recuente, esporádico o archivo) y para cualquier opción de
replicación (LRS, GRS o ZRS ).
Capacidad reservada de SQL Database: la cobertura del descuento depende del nivel de rendimiento elegido.
Para más información, vea Aprenda cómo se aplica un descuento en la reserva de Azure a las instancias de SQL
Database.
Capacidad reservada de Azure Cosmos DB: la cobertura del descuento depende del rendimiento
aprovisionado. Para más información, vea Aplicación del descuento por reserva a Azure Cosmos DB.
Notificaciones de reserva
En función de cómo paga la suscripción de Azure, enviaremos notificaciones de reservas por correo electrónico a
los siguientes usuarios de su organización. Se envían notificaciones para varios eventos, entre los que se incluyen:
Purchase
Próxima expiración de la reserva
Expiry
Renovación
Cancelación
Cambio de ámbito
Para clientes con suscripciones de EA:
Se envía una notificación de compra al comprador y a los contactos de notificación de EA.
Otras notificaciones del ciclo de vida de la reserva solo se envían a los contactos de notificación de EA.
Los usuarios que se agregan a una reserva a través del permiso de RBAC (IAM ) no reciben ninguna
notificación por correo electrónico.
Para clientes con suscripciones individuales:
El comprador recibe una notificación de compra.
En el momento de la compra, el propietario de la cuenta de facturación de suscripción recibe una notificación de
compra.
El propietario de la cuenta recibe todas las demás notificaciones.
¿Necesita ayuda? Póngase en contacto con nosotros.
Si tiene alguna pregunta o necesita ayuda, cree una solicitud de soporte técnico.
Pasos siguientes
Para más información acerca de Azure Reservations, consulte los siguientes artículos:
Administración de Azure Reservations
Información sobre el uso de reservas de Azure para suscripciones de pago por uso
Información sobre el uso de reservas para la inscripción Enterprise
Costos de software de Windows no incluidos con reservas
Azure Reservations en el programa del Proveedor de soluciones en la nube (CSP ) del Centro de partners
Más información sobre las reservas para los planes de servicio:
Máquinas virtuales con Azure Reserved VM Instances
Recursos de Azure Cosmos DB con capacidad reservada de Azure Cosmos DB
Recursos de proceso de SQL Database con capacidad reservada de Azure SQL Database Más
información sobre las reservas para planes de software:
Planes de software de Red Hat con reservas de Azure
Planes de software SUSE con reservas de Azure
Flexibilidad en el tamaño de las máquinas virtuales
con Azure Reserved VM Instances
Con una instancia reservada de máquina virtual optimizada para conseguir flexibilidad en el tamaño de la
instancia, la reserva que adquiera se puede aplicar a los tamaños de las máquinas virtuales del mismo grupo de
flexibilidad de tamaño de instancia. Por ejemplo, si compra una reserva para un tamaño de máquina virtual de la
serie DSv2 como, por ejemplo, Standard_DS5_v2, el descuento por la reserva se puede aplicar a los otros cuatro
tamaños que aparecen en el mismo grupo de flexibilidad de tamaño de instancia:
Standard_DS1_v2
Standard_DS2_v2
Standard_DS3_v2
Standard_DS4_v2
Pero ese descuento de reserva no se aplica a los tamaños de máquinas virtuales que aparecen en grupos de
flexibilidad de tamaño de instancia diferentes, como las SKU en la serie DSv2 de memoria alta:
Standard_DS11_v2, Standard_DS12_v2, etc.
Dentro del grupo de flexibilidad de tamaño de instancia, el número de máquinas virtuales al que se aplica el
descuento por la reserva depende del tamaño de máquina virtual que elija al comprar una reserva. También
depende de los tamaños de las máquinas virtuales que tenga en ejecución. La columna de relación compara la
superficie relativa para cada tamaño de máquina virtual en ese grupo de flexibilidad de tamaño de instancia. Use
el valor de relación para calcular cómo se aplica el descuento por la reserva a las máquinas virtuales que tiene en
ejecución.
Ejemplos
Los ejemplos siguientes usan los tamaños y relaciones en la tabla de la serie DSv2.
Va a comprar una instancia reservada de máquina virtual con el tamaño Standard_DS4_v2 en la que la relación o
superficie relativa comparada con los otros tamaños de esa serie es 8.
Escenario 1: Ejecución de ocho máquinas virtuales de tamaño Standard_DS1_v2 con una relación de 1. El
descuento por la reserva se aplica a las ocho máquinas virtuales.
Escenario 2: Ejecución de máquinas virtuales de tamaño Standard_DS2_v2 con una relación de 2 cada una.
También se ejecuta una máquina virtual con tamaño Standard_DS3_v2 con una relación de 4. La superficie
total es 2+2+4=8. Por tanto, el descuento por la reserva se aplica a las tres máquinas virtuales.
Escenario 3: Ejecución de una máquina virtual de tamaño Standard_DS5_v2 con una relación de 16. El
descuento por la reserva se aplicaría a la mitad del costo de proceso de esa máquina virtual.
En las siguientes secciones se muestra qué tamaños están en el mismo grupo de serie de tamaño cuando compra
una instancia reservada de máquina virtual optimizada con flexibilidad de tamaño.
Relación de flexibilidad de tamaño de instancia para máquinas

virtuales
El siguiente CSV contiene los grupos, ArmSkuName y las relaciones de flexibilidad de tamaño de la instancia.
Relaciones de flexibilidad de tamaño de instancia
La dirección URL del archivo y el esquema se mantendrán fijos para que pueda consumir este archivo mediante
programación. En breve, los datos también estarán disponibles a través de la API.
Vista previa: Hosts dedicados de Azure
Azure Dedicated Host es un servicio que proporciona servidores físicos (capaces de hospedar una o varias
máquinas virtuales) dedicados a una suscripción a Azure. Los hosts dedicados son los mismos servidores físicos
que se usan en nuestros centros de datos y se proporcionan como un recurso. Puede aprovisionar hosts
dedicados dentro de una región, zona de disponibilidad y dominio de error. Después, puede colocar las máquinas
virtuales directamente en los hosts aprovisionados, en la configuración que más se ajuste a sus necesidades.
IMPORTANT
Los hosts dedicados de Azure están actualmente en versión preliminar pública. Esta versión preliminar se ofrece sin Acuerdo
de Nivel de Servicio y no se recomienda para cargas de trabajo de producción. Es posible que algunas características no sean
compatibles o que tengan sus funcionalidades limitadas. Para más información, consulte Términos de uso complementarios
de las Versiones Preliminares de Microsoft Azure.
Limitaciones conocidas de la versión preliminar
Actualmente, los conjuntos de escalado de máquinas virtuales no se admiten en los hosts dedicados.
La versión preliminar inicial admite las siguientes series de máquinas virtuales: DSv3 y ESv3.
Durante la versión preliminar, no podrá cambiar el tamaño de las máquinas virtuales implementada en los hosts
dedicados.
El control sobre las funcionalidades de mantenimiento se encuentra en una versión preliminar limitada. Para probarla, lo
primero que debe hacer es esta encuesta de nominación.
Durante la versión preliminar, no vamos a ofrecer la opción de capacidad reservada.
Ventajas
La reserva de todo el host proporciona las siguientes ventajas:
Aislamiento del hardware a nivel de servidor físico. No se colocarán otras máquinas virtuales en los hosts. Los
hosts dedicados se implementan en los mismos centros de datos y comparten la misma red y la misma
infraestructura de almacenamiento subyacente que otros hosts no aislados.
Control sobre los eventos de mantenimiento iniciados por la plataforma Azure. Aunque la mayoría de los
eventos de mantenimiento tienen poco o ningún impacto en las máquinas virtuales, hay algunas cargas de
trabajo confidenciales en las que cada segundo de pausa puede tener un impacto. Con los hosts dedicados,
puede participar en una ventana de mantenimiento para reducir el impacto en el servicio.
Con la ventaja híbrida de Azure, puede traer sus propias licencias para Windows y SQL a Azure. El uso de las
ventajas híbridas proporciona ventajas adicionales. Para más información, consulte Ventaja híbrida de Azure.
Grupos, hosts y máquinas virtuales
Un grupo host es un recurso que representa una colección de hosts dedicados. Puede crear un grupo host en
una región y una zona de disponibilidad, y agregarle hosts.
Un host es un recurso que se asigna a un servidor físico en un centro de datos de Azure. El servidor físico se
asigna cuando se crea el host. Un host se crea dentro de un grupo host. Un host tiene una SKU que describe qué
tamaños de máquina virtual se pueden crear. Cada host puede hospedar varias máquinas virtuales, de diferentes
tamaños, siempre y cuando sean de la misma serie de tamaño.
Al crear una máquina virtual en Azure, puede seleccionar el host dedicado que se va a usar para la máquina
virtual. Tiene control total sobre las máquinas virtuales que se colocan en los hosts.
Consideraciones acerca de la alta disponibilidad

Para lograr una alta disponibilidad, debe implementar varias máquinas virtuales, que se distribuyen entre varios
hosts (un mínimo de 2). Con Azure Dedicated Host, tiene varias opciones para aprovisionar su infraestructura
para dar forma a sus límites de aislamiento de errores.
Uso de las zonas de disponibilidad para el aislamiento de errores
Las zonas de disponibilidad son ubicaciones físicas exclusivas dentro de una región de Azure. Cada zona de
disponibilidad consta de uno o varios centros de datos equipados con alimentación, refrigeración y redes
independientes. Un grupo host se crea en una zona de disponibilidad individual. Una vez creada, todos los hosts
se colocarán dentro de esa zona. Para lograr una alta disponibilidad entre zonas, es preciso crear varios grupos
host (uno por zona) y distribuir los hosts en consecuencia.
Si asigna un grupo host a una zona de disponibilidad, todas las máquinas virtuales creadas en ese host deben
crearse en la misma zona.
Uso de dominios de error para el aislamiento de errores
Se puede crear un host en un dominio de error específico. Al igual que las máquinas virtuales de un conjunto de
escalado o de un conjunto de disponibilidad, los hosts de distintos dominios de error se colocarán en distintos
bastidores físicos del centro de datos. Al crear un grupo host, es necesario especificar el número de dominios de
error. Al crear hosts en el grupo host, se asigna un dominio de error a cada host. Las máquinas virtuales no
requieren ninguna asignación de dominio de error.
Los dominios de error no son lo mismo que la colocación. Tener el mismo dominio de error para dos hosts no
significa que estén próximos entre sí.
El ámbito de los dominios de error es el grupo host. No debe realizar ninguna suposición sobre la antiafinidad
entre dos grupos host (a menos que se encuentren en zonas de disponibilidad diferentes).
Las máquinas virtuales implementadas en hosts con distintos dominios de error, tendrán sus servicios
subyacentes de Managed Disks en varias marcas de almacenamiento, con el fin de aumentar la protección del
aislamiento de errores.
Uso de zonas de disponibilidad y dominios de error
Puede usar ambas funcionalidades juntas para lograr un mayor aislamiento de los errores. En este caso,
especificará la zona de disponibilidad y el número de dominios de error en cada grupo de hosts, asignará un
dominio de error a cada uno de los hosts del grupo y asignará una zona de disponibilidad a cada una de las
máquinas virtuales
La plantilla de ejemplo de Resource Manager que se encuentra aquí usa zonas y dominios de error para distribuir
los hosts para obtener la máxima resistencia en una región.
Control de mantenimiento
En ocasiones, es posible que la infraestructura que da soporte a las máquinas virtuales se actualice para mejorar
la confiabilidad, el rendimiento, la seguridad y para iniciar nuevas características. La plataforma Azure intenta
minimizar el impacto del mantenimiento de la plataforma siempre que sea posible, pero los clientes con cargas de
trabajosensibles al mantenimiento no pueden tolerar los pocos segundos en los que la máquina virtual debe estar
sin funcionamiento o congelada para realizar el mantenimiento.
El control del mantenimiento proporciona a los clientes una opción para omitir las actualizaciones de
plataforma normales programadas en sus hosts dedicados y, después, aplicarlas en el momento que prefieran en
un periodo acumulado de 35 días.
NOTE
El control de mantenimiento se encuentra actualmente en una fase de versión preliminar limitada y requiere un proceso de
incorporación. Solicite esta versión preliminar mediante el envío de una encuesta de nominación.
Consideraciones de capacidad
Una vez que se aprovisiona un host dedicado, Azure lo asigna a un servidor físico. De esta forma se garantiza la
disponibilidad de la capacidad cuando se necesita aprovisionar la máquina virtual. Azure usa toda la capacidad de
la región (o zona) para elegir un servidor físico para el host. También significa que los clientes pueden esperar
poder aumentar la superficie de su host dedicado sin tener que preocuparse de quedarse sin espacio en el clúster.
Cuotas
Existe un límite de cuota predeterminado por región de 3000 vCPU para hosts dedicados. Sin embargo, el
número de hosts que puede implementar también está limitado por la cuota de la familia de tamaños de máquina
virtual que se usa para el host. Por ejemplo, una suscripción de pago por uso solo puede tener una cuota de 10
vCPU disponibles para la serie de tamaños Dsv3 en la región Este de EE. UU. En este caso, debe solicitar un
aumento de la cuota a un mínimo de 64 vCPU para poder implementar un host dedicado. Seleccione el botón
Solicitar aumento en la esquina superior derecha para archivar una solicitud, si es necesario.
Para más información, consulte Cuotas de vCPU de máquinas virtuales.

La evaluación gratuita y las suscripciones a MSDN no tienen cuota para los hosts dedicados de Azure.
Precios
A los usuarios se les cobra por host dedicado, independientemente del número de máquinas virtuales que se
implementen. En el extracto mensual, verá un nuevo tipo de recurso facturable de hosts. Las máquinas virtuales
de un host dedicado se seguirán mostrando en la instrucción, pero su precio será 0.
El precio del host se establece en función de la familia de máquinas virtuales, del tipo (tamaño de hardware) y de
la región. El precio de un host tiene que ver con el tamaño de máquina virtual mayor que admita el host.
Las licencias de software, el almacenamiento y el uso de la red se facturan por separado del host y las máquinas
virtuales. No hay ningún cambio en esos elementos facturables.
Para más información, consulte Precios de Azure Dedicated Host.
Familias de máquinas virtuales y generaciones de hardware

Se define una SKU para un host y representa el tipo y la serie de tamaño de máquina virtual. Puede mezclar
varias máquinas virtuales de distintos tamaños en un solo host, siempre que no sean de la misma serie de
tamaño. El tipo es la generación de hardware disponible actualmente en la región.
Los distintos types de la misma serie de máquinas virtuales serán de distintos proveedores de CPU y tendrán
diferentes generaciones de CPU y número de núcleos.
Para más información, consulte la página de precios de hosts.
Durante la versión preliminar, se admitirán los siguientes tipos/SKU de host: DSv3_Type1 y ESv3_Type1
Ciclo de vida del host

Azure supervisa y administra el estado de mantenimiento de los hosts. Al consultar el host se devolverán los
siguientes estados:
ESTADO DE MANTENIMIENTO DESCRIPCIÓN
Host disponible No hay ningún problema conocido en el host.
Host bajo investigación Hay algunos problemas en el host y se están examinando. Se

trata de un estado transitorio necesario para que Azure
intente identificar el ámbito y la causa principal del problema
identificado. Es posible que se vean afectadas las máquinas
virtuales que se ejecutan en el host.
Host pendiente de desasignación Azure no puede devolver el host a un estado correcto y le

solicita que vuelva a implementar las máquinas virtuales fuera
de este host. Si autoReplaceOnFailure está habilitado, las
máquinas virtuales se recuperan con un hardware que
funcione correctamente. De lo contrario, es posible que la
máquina virtual se esté ejecutando en un host que esté a
punto de producir un error.
Host desasignado Todas las máquinas virtuales se han quitado del host. Ya no
se le cobrará por este host, ya que el hardware se eliminado
de la rotación.
Pasos siguientes
Puede implementar un host dedicado mediante Azure PowerShell, el portal y la CLI de Azure.
Aquí encontrará una plantilla de ejemplo en la que se usan zonas y dominios de error para obtener la
máxima resistencia en una región.
Introducción a los discos administrados de Azure
Un disco administrado de Azure es un disco duro virtual (VHD ). Se puede considerar como un disco físico en
un servidor en el entorno local, pero virtualizado. Los discos administrados de Azure se almacenan como
blobs en páginas, que son un objeto de almacenamiento de E/S aleatorio en Azure. Llamamos a administrados
a estos discos porque es una abstracción sobre los blobs en páginas, los contenedores de blobs y las cuentas
de almacenamiento de Azure. Con los discos administrados, lo único que debe hacer es aprovisionar el disco y
Azure se encarga del resto.
Cuando se selecciona usar discos administrados de Azure con las cargas de trabajo, Azure crea y administra el
disco automáticamente. Los tipos de discos disponibles son discos ultra, unidades de estado sólido (SSD )
premium, SSD estándar y unidades de disco duro estándar (HDD ). Para más información acerca de cada tipo
de disco individual, consulte Selección de un tipo de disco para máquinas virtuales IaaS .
Ventajas de los discos administrados

Vamos a examinar algunas de las ventajas que se obtienen al usar discos administrados.
Mayor durabilidad y disponibilidad
Los discos administrados están diseñados para ofrecer una disponibilidad del 99,999 %. Para conseguir esto,
proporcionan tres réplicas de los datos, lo que permite una gran durabilidad. Si una o incluso dos réplicas
experimentan problemas, las réplicas restantes garantizan la persistencia de los datos y una gran tolerancia a
errores. Esta arquitectura ha contribuido a que Azure destaque en el sector por ofrecer, de manera constante,
durabilidad de nivel empresarial para discos de infraestructura como servicio (IaaS ), con una tasa de error
anualizada del 0 %.
La implementación de las máquina virtuales es simple y escalable
Con discos administrados, puede crear hasta 50 000 discos de máquina virtual de un tipo en una suscripción
por región, lo que le permite crear miles de máquinas virtuales en una sola suscripción. Esta característica
también aumenta la escalabilidad de los conjuntos de escalado de máquina virtual, ya que permite crear hasta
1000 máquinas virtuales en un conjunto de escalado de máquina virtual con una imagen de Marketplace.
Integración con conjuntos de disponibilidad
Los discos administrados se integran con conjuntos de disponibilidad para garantizar que los discos de
máquinas virtuales de un conjunto de disponibilidad están suficientemente aislados entre sí para evitar un
único punto de error. Los discos se colocan automáticamente en diferentes unidades de escalado de
almacenamiento (marcas). Si se produce un error en una marca debido a un error de hardware o software,
solo dejarán de funcionar las instancias de máquina virtual con discos de dichas marcas. Por ejemplo, suponga
que tiene una aplicación que se ejecuta en cinco máquinas virtuales y estas están en un conjunto de
disponibilidad. No todos los discos de dichas máquinas virtuales se almacenarán en la misma marca, por lo
que, si se produce un error en una, no se detiene la ejecución de las restantes instancias de la aplicación.
Integración con Availability Zones
Los discos administrados admiten Availability Zones, que son una oferta de alta disponibilidad que protege las
aplicaciones de los errores del centro de datos. Las zonas de disponibilidad son ubicaciones físicas exclusivas
dentro de una región de Azure. Cada zona de disponibilidad consta de uno o varios centros de datos
equipados con alimentación, refrigeración y redes independientes. Para garantizar la resistencia, hay tres zonas
independientes como mínimo en todas las regiones habilitadas. Con las zonas de disponibilidad, Azure ofrece
el mejor Acuerdo de Nivel de Servicio del sector de tiempo de actividad de máquina virtual, con un 99,99 %.
Soporte técnico de Azure Backup
Para protegerse frente a desastres regionales, se puede usar Azure Backup para crear un trabajo de copia de
seguridad con copias de seguridad basadas en el tiempo y directivas de retención de copia de seguridad. Esto
le permite realizar restauraciones sencillas de máquinas virtuales a voluntad. Actualmente, Azure Backup
admite tamaños de disco de hasta cuatro tebibytes (TiB ). Azure Backup admite la copia de seguridad y la
restauración de discos administrados. Más información sobre la compatibilidad con la copia de seguridad de
máquinas virtuales de Azure.
Control de acceso pormenorizado
Puede usar el control de acceso basado en rol de Azure (RBAC ) para asignar a uno o varios usuarios permisos
concretos a un disco administrado. Los discos administrados exponen varias operaciones, entre las que se
incluyen la lectura, la escritura (creación o actualización), la eliminación y la recuperación de un identificador
URI de la firma de acceso compartido (SAS ) para el disco. Puede conceder acceso solo a las operaciones
necesarias para que una persona pueda realizar su trabajo. Por ejemplo, si no desea que una persona copie un
disco administrado a una cuenta de almacenamiento, puede decidir no conceder acceso a la acción de
exportación de dicho disco administrado. De igual forma, si no desea que una persona use URI de SAS para
copiar un disco administrado, puede elegir no conceder dicho permiso al disco administrado.
Carga de un disco duro virtual
La carga directa facilita la transferencia de un disco duro virtual a un disco administrado de Azure.
Anteriormente, había que seguir un proceso más complicado que incluía el almacenamiento provisional de los
datos en una cuenta de almacenamiento. Ahora, hay que dar menos pasos. Es más fácil cargar máquinas
virtuales locales en Azure, cargarlas en discos administrados grandes y el proceso de copia de seguridad y
restauración se simplifica. También reduce los costos, ya que permite cargar los datos en discos administrados
directamente sin necesidad de conectarlos a máquinas virtuales. Puede usar la carga directa para cargar discos
duros virtuales de un máximo de 32 TiB.
Para aprender a transferir un disco duro virtual a Azure, consulte los artículos acerca de la CLI o de
PowerShell.
Cifrado
Los discos administrados ofrecen dos tipos diferentes de cifrado. El primero de ellos es Storage Service
Encryption (SSE ), que se realiza mediante el servicio de almacenamiento. El segundo es Azure Disk Encryption
(ADE ), que se puede habilitar en los discos de datos y del sistema operativo de las máquinas virtuales.
Cifrado del servidor
Azure Storage Service Encryption proporciona cifrado en reposo y protege sus datos con el fin de cumplir con
los compromisos de cumplimiento y seguridad de su organización. Storage Service Encryption está habilitado
de forma predeterminada para todos los discos administrados, instantáneas e imágenes en todas las regiones
donde hay discos administrados. Puede permitir que Azure administre sus claves, que son claves
administradas por la plataforma, o puede administrar las claves por su cuenta, ya que son claves administradas
por el cliente (versión preliminar). Visite la página de preguntas más frecuentes sobre discos administrados
para obtener más detalles.
Azure Disk Encryption le permite cifrar los discos de datos y del sistema operativo usados por una máquina
virtual de IaaS. Este cifrado incluye discos administrados. Para Windows, las unidades se cifran mediante la
tecnología de cifrado de BitLocker estándar del sector. Para Linux, los discos se cifran mediante la tecnología
DM -Crypt. El proceso de cifrado se integra con Azure Key Vault para permitirle controlar y administrar las
claves de cifrado del disco. Para más información, consulte Azure Disk Encryption para máquinas virtuales
IaaS.
Roles de disco
Hay tres roles principales de disco en Azure: el disco de datos, el disco del sistema operativo y el disco
temporal. Estos roles se asignan a los discos que están conectados a la máquina virtual.
Disco de datos
Un disco de datos es un disco administrado que se asocia a una máquina virtual para almacenar datos de
aplicaciones u otros datos que necesita mantener. Los discos de datos se registran como unidades SCSI y se
etiquetan con una letra elegida por usted. Cada disco de datos tiene una capacidad máxima de 32767 gibibytes
(GiB ). El tamaño de la máquina virtual determina cuántos discos de datos puede conectar y el tipo de
almacenamiento que puede usar para hospedar los discos.
Disco del sistema operativo
Cada máquina virtual tiene un disco de sistema operativo acoplado. Ese disco del sistema operativo tiene un
sistema operativo instalado previamente, que se seleccionó cuando se creó la máquina virtual. Este disco
contiene el volumen de arranque.
Su capacidad máxima es de 2048 GiB.
Disco temporal
Cada máquina virtual contiene un disco temporal, que no es un disco administrado. El disco temporal
proporciona almacenamiento a corto plazo para aplicaciones y procesos, y está destinado únicamente a
almacenar datos como archivos de paginación o de intercambio. Los datos del disco temporal pueden
perderse durante un evento de mantenimiento o cuando vuelva a implementar una máquina virtual. En
máquinas virtuales Linux de Azure, el disco temporal es /dev/sdb de forma predeterminada; en máquinas
virtuales Windows, el disco temporal es D: de forma predeterminada. Durante un reinicio estándar correcto de
la máquina virtual, se conservarán los datos de la unidad temporal.
Instantáneas de disco administrado

Una instantánea de disco administrado es una copia completa de solo lectura coherente frente a bloqueos de
un disco administrado que, de forma predeterminada, se almacena como disco administrado estándar. Con las
instantáneas, puede realizar una copia de seguridad de sus discos administrados en cualquier momento. Estas
instantáneas existen independientemente del disco de origen y se pueden usar para crear discos
administrados.
Las instantáneas se facturan en función del tamaño utilizado. Por ejemplo, si crea una instantánea de un disco
administrado con capacidad aprovisionada de 64 GiB y el tamaño de datos usado real es de 10 GiB, solo se le
cobra por el tamaño de datos usado de 10 GiB. El tamaño usado de las instantáneas se puede ver en el
informe de uso de Azure. Por ejemplo, si el tamaño de datos usado de una instantánea es de 10 GiB, el
informe de uso diario mostrará 10 GiB/(31 días) = 0,3226 como cantidad consumida.
Para más información sobre cómo crear instantáneas para discos administrados, consulte los siguientes
recursos:
Creación de una instantánea de un disco administrado en Windows
Creación de una instantánea de un disco administrado en Linux
Imágenes
Los discos administrados también admiten la creación de una imagen personalizada administrada. Puede
crear una imagen desde un disco duro virtual personalizado en una cuenta de almacenamiento, o bien
directamente desde una máquina virtual generalizada (con Sysprep). Este proceso captura una imagen única.
Esta imagen contiene todos los discos administrados asociados con una máquina virtual, lo que incluye tanto
el disco de datos como el del sistema operativo. Esta imagen personalizada administrada permite crear cientos
de máquinas virtuales con la imagen personalizada sin necesidad de copiar o administrar cuentas de
almacenamiento.
Para más información sobre la creación de imágenes, consulte los artículos siguientes:
How to capture a managed image of a generalized VM in Azure (Captura de una imagen administrada de
una máquina virtual generalizada en Azure)
How to generalize and capture a Linux virtual machine using the Azure CLI 2.0 (Procedimiento de
generalización y captura de una máquina virtual Linux con la CLI de Azure 2.0)
Imágenes frente a instantáneas
Es importante comprender la diferencia entre imágenes e instantáneas. Con los discos administrados, es
posible tomar una imagen de una máquina virtual generalizada que se ha desasignado. Esta imagen incluye
todos los discos asociados a la máquina virtual. La imagen se puede usar para crear una máquina virtual e
incluye todos los discos.
Una instantánea es una copia de un disco en el momento dado en que se toma. Se aplica solo a un disco. Si
tiene una máquina virtual con un solo disco (el del sistema operativo), puede tomar una instantánea o una
imagen de él y crear una máquina virtual a partir de cualquiera de ellas.
Una instantánea no tiene información sobre ningún disco, excepto el que contiene. Como consecuencia, resulta
problemático usarla en escenarios que requieren la coordinación de varios discos, como la creación de bandas.
Las instantáneas deben poderse coordinar entre sí y esta funcionalidad no se admite actualmente.
Asignación y rendimiento de discos

En el diagrama siguiente se muestra la asignación en tiempo real de ancho de banda e IOPS para los discos
mediante un sistema de aprovisionamiento en tres niveles:
El aprovisionamiento del primer nivel establece la asignación de IOPS y ancho de banda por disco. En el
segundo nivel, el host del servidor de proceso implementa el aprovisionamiento de SSD y lo aplica solo a los
datos que se almacenan en la unidad de estado sólido del servidor, que incluye los discos con almacenamiento
en caché (ReadWrite y ReadOnly), así como los discos locales y temporales. Por último, el aprovisionamiento
de red de VM se realiza en el tercer nivel, para cualquier E/S que el host de proceso envía al back-end de
Azure Storage. En este esquema el rendimiento de una máquina virtual depende de varios factores, desde el
modo en que la máquina virtual usa la unidad de estado sólido local hasta el número de discos conectados, así
como el tipo de rendimiento y almacenamiento en caché de los discos que tiene conectados.
Como ejemplo de estas limitaciones, se evita que una máquina virtual Standard_DS1v1 alcance el potencial de
5 000 IOPS de un disco P30, tanto si está almacenado en caché como si no, debido a los límites en los niveles
de red y SSD:
Azure usa un canal de red con clasificación por orden de prioridad para el tráfico de disco, que tiene
precedencia sobre otras prioridades bajas de tráfico de red. Esto ayuda a los discos a mantener el rendimiento
esperado en caso de contenciones de red. Del mismo modo, Azure Storage controla las contenciones de
recursos y otros problemas en segundo plano, con el equilibrio de carga automático. Azure Storage asigna los
recursos necesarios cuando se crea un disco y aplica un equilibrio proactivo y reactivo de recursos para
controlar el nivel de tráfico. De este modo, se garantiza que los discos pueden mantener sus objetivos de IOPS
y rendimiento esperados. Puede usar las métricas de nivel de máquina virtual y de nivel de disco para realizar
el seguimiento del rendimiento y configurar alertas según sea necesario.
Consulte el artículo sobre diseño de alto rendimiento para conocer los procedimientos recomendados a la
hora de optimizar las configuraciones de máquina virtual y disco, de modo que pueda lograr el rendimiento
deseado.
Pasos siguientes
Más información sobre los tipos de disco individuales que ofrece Azure, cuál es una buena elección para sus
necesidades y sus objetivos de rendimiento en nuestro artículo sobre los tipos de disco.
Selección de un tipo de disco para máquinas virtuales de IaaS
¿Qué tipos de disco están disponibles en Azure?
Actualmente, Azure Managed Disks ofrece cuatro tipos de discos. Cada uno estos tipos está pensado para
escenarios de clientes específicos.
Comparación de discos
La tabla siguiente proporciona una comparación entre los discos Ultra, las unidades de estado sólido (SSD )
premium, los discos SSD estándar y las unidades de disco duro (HDD ) estándar para Managed Disks, a fin de
ayudar a decidir qué opción usar.
DISCO ULTRA SSD PREMIUM SSD ESTÁNDAR HDD ESTÁNDAR
Tipo de disco SSD SSD SSD HDD
Escenario Cargas de trabajo de Cargas de trabajo Servidores web, Copia de seguridad,

uso intensivo de E/S, confidenciales de aplicaciones no crítico, acceso
como SAP HANA, producción y empresariales poco poco frecuente
bases de datos de rendimiento utilizadas y desarrollo
nivel superior (por y pruebas
ejemplo, SQL y
Oracle) y otras cargas
de trabajo con
muchas
transacciones.
Tamaño máximo del 65 536 gibibyte (GiB) 32 767 GiB 32 767 GiB 32 767 GiB
disco
Rendimiento máx. 2000 MiB/s 900 MiB/s 750 MiB/s 500 MiB/s
IOPS máx. 160 000 20.000 6,000 2.000
Disco Ultra
Los discos Ultra de Azure ofrecen un alto rendimiento, un número elevado de IOPS y un almacenamiento en
disco coherente y de baja latencia para máquinas virtuales IaaS de Azure. Algunas ventajas adicionales de los
discos Ultra incluyen la capacidad de cambiar dinámicamente el rendimiento del disco junto con sus cargas de
trabajo sin tener que reiniciar las máquinas virtuales. Además, los discos Ultra son adecuados para cargas de
trabajo con grandes cantidades de datos, como SAP HANA, bases de datos de nivel superior y cargas de trabajo
que admitan muchas transacciones. Los discos Ultra solo se pueden utilizar como discos de datos. Por ello,
recomendamos usar los discos SSD Premium como discos de sistema operativo.
Rendimiento
Cuando aprovisione un disco ultra, puede configurar de forma independiente la capacidad y el rendimiento del
disco. Los discos Ultra vienen en varios tamaños fijos que van desde los 4 GiB hasta los 64 TiB y cuentan con un
modelo de configuración de rendimiento flexible que le permite configurar las unidades IOPS y el rendimiento de
forma independiente.
Estas son algunas funcionalidades clave de los discos Ultra:
Capacidad de disco: intervalos de capacidad de discos Ultra desde 4 GiB hasta 64 TiB.
IOPS de disco: los dispositivos Ultra admiten límites de IOPS de 300 IOPS/GiB y hasta un máximo de
160 K IOPS por disco. Para recuperar la tasa de unidades IOPS que aprovisionó, asegúrese de que la cantidad
de IOPS de disco seleccionadas sea menor que el límite de IOPS de la máquina virtual. El valor mínimo de
IOPS por disco es 2 IOPS/GiB, con una línea de base general mínima de 100 IOPS. Por ejemplo, si tuviera un
disco Ultra de 4 GiB, tendrá un mínimo de 100 IOPS, en lugar de ocho IOPS.
Rendimiento del disco: con los discos Ultra, el límite de rendimiento de un solo disco es de 256 KiB/s por cada
IOPS aprovisionada, y hasta 2000 MBps como máximo por disco (donde MBps = 10^6 bytes por segundo).
El rendimiento mínimo por disco es 4KiB/s por cada IOPS aprovisionada, con una línea de base total como
mínima de 1 MBps.
Los discos Ultra admiten el ajuste de los atributos de rendimiento del disco (IOPS y rendimiento) en tiempo
de ejecución sin necesidad de desasociar el disco de la máquina virtual. Cuando se ha enviado una operación
de cambio de tamaño del rendimiento del disco en un disco, este cambio puede tardar hasta una hora en
surtir efecto. Hay un límite de cuatro operaciones de cambio de tamaño de rendimiento en un período de
24 horas. Se puede producir un error en la operación de ajuste de tamaño del rendimiento debido a la falta de
capacidad de ancho de banda de rendimiento.
Tamaño del disco
TAMAÑO DE DISCO (GIB) CAPACIDAD DE IOPS CAPACIDAD DE RENDIMIENTO (MBPS)
4 1,200 300
8 2,400 600
16 4,800 1,200
32 9600 2.000
64 19 200 2.000
128 38 400 2.000
256 76 800 2.000
512 80 000 2.000
1024 - 65 536 (los tamaños de este 160 000 2.000

intervalo aumentan en incrementos de
1 TiB)
Ámbito y limitaciones de la disponibilidad general

Por ahora, los discos Ultra tienen limitaciones adicionales, como se indica a continuación:
Se admiten en las siguientes regiones, con un número variable de zonas de disponibilidad por región:
Este de EE. UU. 2
East US
Oeste de EE. UU. 2
Sudeste Asiático
Europa del Norte
Europa occidental
Sur de Reino Unido 2
Solo se podrán usar con las zonas de disponibilidad (los conjuntos de disponibilidad y las implementaciones
de máquinas virtuales únicas fuera de las zonas no tendrán la capacidad de adjuntar un disco Ultra).
Solo se admiten en las siguientes series de máquinas virtuales:
ESv3
DSv3
FSv2
M
Mv2
No todos los tamaños de máquina virtual están disponibles en todas las regiones admitidas con discos Ultra.
Solo están disponibles como discos de datos y solo admiten el tamaño de sector físico 4k.
Solo pueden crearse como discos vacíos.
Todavía no admiten instantáneas de disco, imágenes de máquinas virtuales, conjuntos de disponibilidad ni
Azure Disk Encryption.
Todavía no admiten la integración con Azure Backup o Azure Site Recovery.
El límite máximo actual de IOPS en máquinas virtuales de disponibilidad general es 80 000.
Si quiere empezar con un disco ultra, vea nuestro artículo sobre el tema: Uso de discos Ultra de Azure.
SSD Premium
Los discos SSD Premium de Azure ofrecen soporte de disco de alto rendimiento y latencia baja para máquinas
virtuales (VM ) con cargas de trabajo con uso intensivo de entrada/salida (E/S ). Para aprovechar la ventaja de la
velocidad y el rendimiento de discos de Premium Storage, puede migrar los discos de VM existentes a SSD
Premium. Los discos SSD Premium son adecuados para aplicaciones de producción críticas. Los discos SSD
Premium solo se pueden usar con series de máquinas virtuales que sean compatibles con el almacenamiento
premium.
Para más información sobre los tipos individuales de máquinas virtuales y los tamaños de Azure para Windows,
incluidos los tamaños que son compatibles con el almacenamiento premium, consulte Tamaños de máquina
virtual Windows. Para más información sobre los tipos individuales de máquinas virtuales y los tamaños de
Azure para Linux, incluidos los tamaños que son compatibles con el almacenamiento premium, consulte Tamaños
de máquina virtual Linux.
Tamaño del disco
TAM
AÑO
S DE
SSD
PRE
MIU
Tam 4 8 16 32 64 128 256 512 102 2 4 819 16 32

año 4 048 096 2 384 767
de
disc
o
en
GiB
IOP 120 120 120 120 240 500 110 2,3 5.0 750 750 16 18 20.0
S 0 00 00 0 0 000 000 00
por
disc
o
TAM
AÑO
S DE
SSD
PRE
MIU
Ren 25 25 25 25 50 100 125 150 200 250 250 500 750 900
o
de
disc
o.
Máx 350 350 350 350 350 350 350 350

imo 0 0 0 0 0 0 0 0
de
IOP
S de
ráfa
ga
por
disc
o**
Ren 170 170 170 170 170 170 170 170

o
máx
imo
de
ráfa
ga
por
disc
o**
Dur 30 30 30 30 30 30 30 30
n
máx
ima
de
ráfa
ga*
*
**Indica una característica que se encuentra actualmente en versión preliminar; consulte Envío de ráfagas en
disco para más información.
Cuando se aprovisiona un disco de Premium Storage, a diferencia de Standard Storage, se garantizan la
capacidad, las E/S por segundo y el rendimiento del mismo. Por ejemplo, si crea un disco P50, Azure aprovisiona
una capacidad de almacenamiento de 4095 GB, 7500 E/S por segundo y un rendimiento de 250 MB/s para él. La
aplicación puede usar toda la capacidad y el rendimiento o parte de ellos. Los discos SSD Premium están
diseñados para proporcionar bajas latencias inferiores a 10 milisegundos y un IOPS y rendimiento que se
describen en la tabla anterior como del 99,9 % del tiempo.
Creación de ráfagas (versión preliminar)
Los tamaños de SSD Premium más pequeños que P30 ahora ofrecen una ráfaga de disco (versión preliminar) y
pueden aumentar los IOPS por disco en hasta 3.500 y el ancho de banda en hasta 170 Mbps. La creación de
ráfagas está automatizada y funciona de acuerdo con un sistema de crédito. Los créditos se acumulan
automáticamente en un depósito de ráfagas cuando el tráfico del disco está por debajo del objetivo de
rendimiento aprovisionado y los créditos se consumen automáticamente cuando el tráfico supera el destino,
hasta el límite máximo de ráfagas. El límite máximo de ráfagas define el límite superior de IOPS y Bandwidth del
disco, incluso si tiene créditos de ráfagas para consumir. La ráfaga de disco proporciona una tolerancia mejorada
a cambios imprevisibles en los patrones de E/S. Puede aprovecharla mejor en el arranque del disco del sistema
operativo y las aplicaciones con tráfico de picos.
La compatibilidad con ráfagas de discos se habilitará en las nuevas implementaciones de los tamaños de disco
aplicables en las regiones de la versión preliminar de forma predeterminada, sin necesidad de que intervenga el
usuario. En el caso de los discos existentes de tamaños aplicables, puede habilitar la ráfaga con cualquiera de
estas dos opciones: desasociar y volver a adjuntar el disco, o detener y reiniciar la VM conectada. Todos los
tamaños de disco aplicables de la ráfaga comenzarán con un cubo de crédito de ráfaga completo cuando el disco
esté conectado a una máquina virtual que admita una duración máxima en el límite máximo de ráfaga de 30
minutos. Para obtener más información sobre el aumento del trabajo de ráfagas en discos de Azure, consulte
Creación de ráfagas SSD Premium.
Transacciones
Para los discos SSD Premium, cada operación de E/S menor o igual a 256 KiB de rendimiento se considera una
sola operación de E/S. Las operaciones de E/S mayores de 256 KiB de rendimiento se consideran múltiplos de
operaciones de E/S con un tamaño de 256 KiB.
SSD estándar
Los discos SSD estándar de Azure son una opción de almacenamiento rentable, optimizada para cargas de
trabajo que necesitan un rendimiento constante en niveles inferiores de IOPS. Los discos SSD estándar ofrecen
una buena experiencia de nivel de entrada para aquellos que desean pasarse a la nube, en especial si tiene
problemas con la variación de las cargas de trabajo que se ejecutan en las soluciones de disco duro locales. En
comparación con los discos HDD estándar, los discos SSD estándar ofrecen mayor disponibilidad, coherencia,
confiabilidad y latencia. Los discos SSD estándar son convenientes para servidores web, servidores de
aplicaciones con IOPS bajas, aplicaciones empresariales de poco uso y cargas de trabajo de desarrollo/pruebas.
Al igual que los discos HDD estándar, los SSD están disponibles en todas las máquinas virtuales de Azure.
Tamaño del disco
TAM
AÑO
S DE
SSD
EST
ÁND
AR E1* E2* E3* E4 E6 E10 E15 E20 E30 E40 E50 E60 E70 E80
Tam 4 8 16 32 64 128 256 512 102 2 4 819 16 32

año 4 048 096 2 384 767
de
disc
o
en
GiB
TAM
AÑO
S DE
SSD
EST
ÁND
IOP Has Has Has Has Has Has Has Has Has Has Has Has Has Has
S ta ta ta ta ta ta ta ta ta ta ta ta ta ta
por 120 120 120 120 240 500 500 500 500 500 500 200 400 600
disc 0 0 0
o
Ren Has Has Has Has Has Has Has Has Has Has Has Has Has Has
dimi ta ta ta ta ta ta ta ta ta ta ta ta ta ta
ent 25 25 25 25 50 60 60 60 60 60 60 400 600 750
o MiB MiB MiB MiB MiB MiB MiB MiB MiB MiB MiB Mi Mi MiB
de /s /s /s /s /s /s /s /s /s /s /s B/s B/s /s
disc
o.
Los discos SSD estándar están diseñados para proporcionar latencias de menos de 10 milisegundos y un nivel de
IOPS y de rendimiento hasta los límites descritos en la tabla anterior durante el 99 % del tiempo. Las IOPS y el
rendimiento reales pueden variar a veces, según los patrones de tráfico. Los discos SSD estándar proporcionarán
un rendimiento más coherente que los discos HDD, con una latencia menor.
Transacciones
Para los discos SSD estándar, cada operación de E/S menor o igual a 256 KiB de rendimiento se considera una
sola operación de E/S. Las operaciones de E/S mayores de 256 KiB de rendimiento se consideran múltiplos de
operaciones de E/S con un tamaño de 256 KiB. Estas transacciones tienen un impacto en la facturación.
HDD estándar
Los discos HDD estándar de Azure ofrecen compatibilidad de discos confiable y de bajo coste para las máquinas
virtuales que ejecutan cargas de trabajo que no tienen en cuenta la latencia. Con Standard Storage, los datos se
almacenan en unidades de disco duro (HDD ). La latencia, las IOPS y el rendimiento de los discos HDD estándar
pueden variar más en comparación con los discos basados en SSD. Los discos HDD estándar están diseñados
para ofrecer latencias de escritura inferiores a 10 ms y latencias de lectura inferiores a 20 ms para la mayoría de
las operaciones de E/S, aunque el rendimiento real puede variar según el tamaño de E/S y el patrón de carga de
trabajo. Cuando se trabaja con máquinas virtuales, se pueden usar discos HDD estándar para escenarios de
desarrollo/pruebas y para cargas de trabajo menos críticas. Los discos HDD estándar están disponibles en todas
las regiones de Azure y se pueden utilizar con todas las máquinas virtuales de Azure.
Tamaño del disco
TIPO
DE
DISCO
ESTÁN
DAR S4 S6 S10 S15 S20 S30 S40 S50 S60 S70 S80
Tama 32 64 128 256 512 1024 2 048 4 096 8192 16 32

ño de 384 767
disco
en
GiB
IOPS Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta
por 500 500 500 500 500 500 500 500 1300 2000 2000
disco
Rendi Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta
mient 60 60 60 60 60 60 60 60 300 500 500
o de MiB/s MiB/s MiB/s MiB/s MiB/s MiB/s MiB/s MiB/s MiB/s MiB/s MiB/s
disco.
Transacciones
En el caso de los discos HDD estándar, cada operación de E/S se considera como una única transacción,
independientemente del tamaño de esta. Estas transacciones tienen un impacto en la facturación.
Facturación
Al usar Managed Disks, se aplican las siguientes consideraciones de facturación:
Tipo de disco
Tamaño del disco administrado
Instantáneas
Transferencias de datos de salida
Número de transacciones
Tamaño del disco administrado: los discos administrados se facturan por el tamaño aprovisionado. Azure
asigna el tamaño aprovisionado (redondeado al alza) a la oferta de tamaño de disco más cercana. Para obtener
detalles sobre los tamaños de disco ofrecidos, consulte las tablas anteriores. Cada disco se asigna a una oferta de
tamaño de disco aprovisionado compatible y se factura según corresponda. Por ejemplo, si ha aprovisionado un
disco SSD estándar de 200 GiB, se asigna a la oferta de tamaño de disco E15 (256 GiB ). La facturación de
cualquier disco aprovisionado se prorratea cada hora con el precio mensual de la oferta de Premium Storage. Por
ejemplo, si ha aprovisionado un disco E10 y lo ha eliminado después de 20 horas, se factura la oferta E10
prorrateada a 20 horas. Esto es así independientemente de la cantidad de datos que se escriba en el disco.
Instantáneas: Las instantáneas se facturan según el tamaño utilizado. Por ejemplo, si crea una instantánea de un
disco administrado con capacidad aprovisionada de 64 GiB y el tamaño de datos usado real es de 10 GiB, solo se
le cobra por el tamaño de datos usado de 10 GiB.
Para más información acerca de las instantáneas, consulte la sección sobre las instantáneas en la introducción a
los discos administrados.
Transferencias de datos de salida: transferencias de datos de salida (datos que salen de los centros de datos de
Azure) incurren en la facturación por el uso de ancho de banda.
Transacciones: se le factura por el número de transacciones que realiza en un disco administrado estándar. Para
los discos SSD estándar, cada operación de E/S menor o igual a 256 KiB de rendimiento se considera una sola
operación de E/S. Las operaciones de E/S mayores de 256 KiB de rendimiento se consideran varias operaciones
de E/S con un tamaño de 256 KiB. En el caso de los discos HDD estándar, cada operación de E/S se considera
como una única transacción, independientemente del tamaño de esta.
Para obtener información detallada sobre los precios de Managed Disks, incluidos los costes de las transacciones,
consulte Precios de Managed Disks.
Precio de reserva de máquina virtual para discos Ultra
Las máquinas virtuales de Azure tienen la funcionalidad para indicar si son compatibles con discos Ultra. Una
máquina virtual compatible con SSD Ultra asigna capacidad dedicada de ancho de banda entre la instancia de la
máquina virtual de proceso y la unidad de escalado de almacenamiento en bloque, para así poder optimizar el
rendimiento y reducir la latencia. Al agregar esta funcionalidad en la máquina virtual, se crea un cargo por
reserva que solo se cobra si habilita la funcionalidad de discos Ultra en la máquina virtual sin asociarle uno de
estos discos. Cuando un disco Ultra está asociado a la máquina virtual compatible con estos discos, este cargo no
se aplicará. Este cargo se calcula según la vCPU aprovisionada en la máquina virtual.
NOTE
En el caso de los tamaños principales de máquina virtual restringidos, la tarifa de la reserva se basa en el número real de
vCPU y no en los núcleos restringidos. En el caso de Standard_E32-8s_v3, la tarifa de la reserva se basará en 32 núcleos.
Para información sobre los precios de los discos Ultra, consulte la página de precios de discos de Azure.
Reserva de discos de Azure
La reserva de discos es la opción de adquirir de antemano un año de almacenamiento en discos con descuento, lo
que reduce los costos totales. Al comprar una reserva de discos, selecciona una SKU de disco específica en una
región de destino, por ejemplo, 10 SSD Premium de P30 (1 TiB ) en la región Este de EE. UU. 2 por un plazo de
un año. La experiencia de reserva es similar a las instancias reservadas de máquina virtual (VM ). Puede agrupar
las reservas de discos y máquinas virtuales para maximizar el ahorro. Por ahora, la reserva de discos de Azure
ofrece un plan de compromiso de un año para las SKU de SSD Premium de P30 (1 TiB ) a P80 (32 TiB ) en todas
las regiones de producción. Para más información sobre los precios de los discos reservados, consulte la página
de precios de los discos de Azure.
Cifrado del lado servidor de Azure Managed Disks
Los discos administrados de Azure cifran automáticamente los datos de forma predeterminada cuando se guardan
en la nube. El cifrado del lado servidor protege los datos y le ayuda a cumplir los compromisos de cumplimiento y
seguridad de la organización. Los datos de los discos administrados de Azure se cifran de forma transparente
mediante cifrado AES de 256 bits, uno de los cifrados de bloques más sólidos que hay disponibles, y son
compatibles con FIPS 140-2.
El cifrado no afecta al rendimiento de los discos administrados. No hay ningún coste adicional por el cifrado.
Para más información sobre de los módulos criptográficos subyacentes en los discos administrados de Azure,
consulte Cryptography API: Next Generation
Información sobre la administración de claves de cifrado

Puede confiar en las claves administradas por la plataforma para el cifrado del disco administrado o puede
administrar el cifrado con sus propias claves (versión preliminar pública). Si opta por administrar el cifrado con sus
propias claves, puede especificar una clave administrada por el cliente que se usará para cifrar y descifrar todos los
datos de discos administrados.
En las secciones siguientes se describe cada una de las opciones de administración de claves con mayor detalle.
Claves administradas por la plataforma

De forma predeterminada, los discos administrados usan claves de cifrado administradas por la plataforma. A
partir del 10 de junio de 2017, todos los nuevos discos administrados, instantáneas e imágenes, así como los datos
nuevos que se escriban en discos administrados existentes, se cifran automáticamente en reposo con claves
administradas por la plataforma.
Claves administradas por el cliente (versión preliminar pública)

Puede optar por administrar el cifrado en el nivel de cada disco administrado, con sus propias claves. El cifrado del
lado servidor de discos administrados con claves administradas por el cliente ofrece una experiencia integrada con
Azure Key Vault. Puede importar las claves RSA a su instancia de Key Vault o generar nuevas claves RSA en
Azure Key Vault. Azure Managed Disks controla el cifrado y descifrado de forma totalmente transparente con
cifrado de sobre. Cifra los datos con una clave de cifrado de datos (DEK) basada en AES 256, que, a su vez, está
protegida con las claves del usuario. Tiene que conceder acceso a los discos administrados en su instancia de
Key Vault para usar sus propias claves para cifrar y descifrar la clave DEK. Esto le permite controlar completamente
los datos y las claves. Puede deshabilitar las claves o revocar el acceso a los discos administrados en cualquier
momento. También puede auditar el uso de la clave de cifrado con la supervisión de Azure Key Vault para
asegurarse de que solo los discos administrados u otros servicios de Azure de confianza tengan acceso a las claves.
En el siguiente diagrama se muestra cómo los discos administrados utilizan Azure Active Directory y
Azure Key Vault para realizar solicitudes con la clave administrada por el cliente:
En la lista siguiente se explican los pasos numerados del diagrama:
1. Un administrador de Azure Key Vault crea recursos de almacén de claves.
2. El administrador del almacén de claves importa sus claves RSA a Key Vault o genera nuevas claves RSA en
Key Vault.
3. Ese administrador crea una instancia del recurso Conjunto de cifrado de disco y especifica un identificador de
Azure Key Vault y una dirección URL de clave. Conjunto de cifrado de disco es un nuevo recurso que se ha
introducido para simplificar la administración de claves de los discos administrados.
4. Cuando se crea un conjunto de cifrado de disco, se crea una identidad administrada asignada por el sistema en
Azure Active Directory (AD ) y se asocia al conjunto de cifrado de disco.
5. El administrador de Azure Key Vault concede entonces al administrador de la identidad administrada permiso
para realizar operaciones en el almacén de claves.
6. Un usuario de máquina virtual crea discos asociándolos con el conjunto de cifrado de disco. El usuario de la
máquina virtual también puede habilitar el cifrado del lado servidor con claves administradas por el cliente para
los recursos existentes asociándolos al conjunto de cifrado de disco.
7. Los discos administrados usan la identidad administrada para enviar solicitudes a la instancia de
Azure Key Vault.
8. Para leer o escribir datos, los discos administrados envían solicitudes a Azure Key Vault para cifrar (encapsular)
y descifrar (desencapsular) la clave de cifrado de datos con el fin de realizar el cifrado y descifrado de los datos.
Para revocar el acceso a las claves administradas por el cliente, vea PowerShell de Azure Key Vault y CLI de Azure
Key Vault. La revocación del acceso bloquea de manera eficaz el acceso a todos los datos de la cuenta de
almacenamiento, ya que Azure Storage no puede acceder a la clave de cifrado.
Escenarios y restricciones admitidos
En la versión preliminar, solo se admiten los siguientes escenarios:
Cree una máquina virtual (VM ) a partir de una imagen de Azure Marketplace y cifre el disco del sistema
operativo con cifrado del lado servidor y claves administradas por el cliente.
Cree una imagen personalizada cifrada con cifrado del lado servidor y claves administradas por el cliente.
Cree una máquina virtual a partir de una imagen personalizada y cifre el disco del sistema operativo con cifrado
del lado servidor y claves administradas por el cliente.
Cree discos de datos cifrados con cifrado del lado servidor y claves administradas por el cliente.
Cree instantáneas que estén cifradas con cifrado del lado servidor y claves administradas por el cliente.
Cree conjuntos de escalado de máquinas virtuales que estén cifrados con cifrado del lado servidor y claves
administradas por el cliente.
La versión preliminar tiene también las siguientes restricciones:
Solo está disponible en la región Centro-oeste de EE. UU.
Los discos creados a partir de imágenes personalizadas que están cifradas con cifrado del lado servidor y las
claves administradas por el cliente deben cifrarse con las mismas claves administradas por el cliente y deben
estar en la misma suscripción.
Las instantáneas creadas a partir de discos que están cifrados con cifrado del lado servidor y claves
administradas por el cliente deben cifrarse con las mismas claves administradas por el cliente.
Las imágenes personalizadas cifradas con cifrado del lado servidor y claves administradas por el cliente no se
pueden usar en la galería de imágenes compartidas.
La instancia de Key Vault debe encontrarse en la misma región y suscripción que las calves administradas por el
cliente.
Los discos, las instantáneas y las imágenes cifrados con claves administradas por el cliente no se pueden
trasladar a otra suscripción.
Configuración de Azure Key Vault
1. Cree una instancia de Azure Key Vault y la clave de cifrado.
Al crear la instancia de Key Vault, debe habilitar la eliminación temporal y la protección de purgas. La
eliminación temporal garantiza que la instancia de Key Vault conserva una clave eliminada durante un
período de retención determinado (valor predeterminado de 90 días). La protección de purgas garantiza que
una clave eliminada no se puede eliminar permanentemente hasta que transcurra el período de retención.
Esta configuración le protege contra la pérdida de datos debido a la eliminación accidental. Estos valores son
obligatorios cuando se usa una instancia de Key Vault para cifrar discos administrados.
$keyVault = New-AzKeyVault -Name myKeyVaultName `

-ResourceGroupName myRGName `
-Location westcentralus `
-EnableSoftDelete `
-EnablePurgeProtection
$key = Add-AzKeyVaultKey -VaultName $keyVault.VaultName `

-Name myKeyName `
-Destination Software `
2. Cree una instancia de un objeto DiskEncryptionSet.
New-AzResourceGroupDeployment -ResourceGroupName myRGName `

-TemplateUri
"https://raw.githubusercontent.com/ramankumarlive/manageddiskscmkpreview/master/CreateDiskEncryptionSet.
json" `
-diskEncryptionSetName "myDiskEncryptionSet1" `
-keyVaultId
"/subscriptions/mySubscriptionId/resourceGroups/myRGName/providers/Microsoft.KeyVault/vaults/myKeyVaultN
ame" `
-keyVaultKeyUrl
"https://myKeyVaultName.vault.azure.net/keys/myKeyName/403445136dee4a57af7068cab08f7d42" `
-region "WestCentralUS"
3. Conceda al recurso DiskEncryptionSet acceso al almacén de claves.

$identity = Get-AzADServicePrincipal -DisplayName myDiskEncryptionSet1
Set-AzKeyVaultAccessPolicy `
-VaultName $keyVault.VaultName `
-ObjectId $identity.Id `
-PermissionsToKeys wrapkey,unwrapkey,get
New-AzRoleAssignment `
-ObjectId $identity.Id `
-RoleDefinitionName "Reader" `
-ResourceName $keyVault.VaultName `
-ResourceType "Microsoft.KeyVault/vaults" `
-ResourceGroupName myRGName `
Creación de una máquina virtual con una imagen de Marketplace, cifrado del sistema operativo y de los discos
de datos con claves administradas por el cliente a través de una plantilla de Resource Manager
$password=ConvertTo-SecureString -String "myVMPassword" `

-AsPlainText -Force
New-AzResourceGroupDeployment -ResourceGroupName CMKTesting `
-TemplateUri
"https://raw.githubusercontent.com/ramankumarlive/manageddiskscmkpreview/master/CreateVMWithDisksEncryptedWithC
MK.json" `
-virtualMachineName "myVMName" `
-adminPassword $password `
-vmSize "Standard_DS3_V2" `
-diskEncryptionSetId
"/subscriptions/mySubscriptionId/resourceGroups/myRGName/providers/Microsoft.Compute/diskEncryptionSets/myDiskE
ncryptionSet1" `
-region "westcentralus"
Creación de un disco vacío cifrado con cifrado del lado servidor y claves administradas por el cliente y su
conexión a una máquina virtual
$vmName = "yourVMName"
$rgName = "yourRGName"
$diskName = "yourDiskName"
$diskSKU = "Premium_LRS"
$diskSizeinGiB = "30"
$diskEncryptionSetId =
"/subscriptions/<subscriptionID>/resourceGroups/yourRGName/providers/Microsoft.Compute/diskEncryptionSets/<your
DiskEncryptionSetName>"
$region = "westcentralus"
$diskLUN = 1
New-AzResourceGroupDeployment -ResourceGroupName $rgName `

-TemplateUri
"https://raw.githubusercontent.com/ramankumarlive/manageddiskscmkpreview/master/CreateEmptyDataDiskEncryptedWit
hSSECMK.json" `
-diskName $diskName `
-diskSkuName $diskSKU `
-dataDiskSizeInGb $diskSizeinGiB `
-diskEncryptionSetId $diskEncryptionSetId `
-region $region
$vm = Get-AzVM -Name $vmName -ResourceGroupName $rgName

$disk = Get-AzDisk -DiskName $diskName -ResourceGroupName $rgName
$vm = Add-AzVMDataDisk -VM $vm -Name $diskName -CreateOption Attach -ManagedDiskId $disk.Id -Lun 1
Update-AzVM -ResourceGroupName $rgName -VM $vm
IMPORTANT
Las claves administradas por el cliente dependen de identidades administradas para los recursos de Azure, una característica
de Azure Active Directory (Azure AD). Al configurar claves administradas por el cliente, se asigna automáticamente una
identidad administrada a los recursos en segundo plano. Si posteriormente mueve la suscripción, el grupo de recursos o el
disco administrado de un directorio de Azure AD a otro, la identidad administrada asociada a los discos administrados no se
transfiere al nuevo inquilino, por lo que es posible que las claves administradas por el cliente dejen de funcionar. Para obtener
más información, consulte Transferencia de una suscripción entre directorios de Azure AD.
Cifrado del lado servidor frente a Azure Disk Encryption

Azure Disk Encryption aprovecha la característica BitLocker de Windows y la característica DM -Crypt de Linux
para cifrar los discos administrados con claves administradas por el cliente dentro de la máquina virtual invitada. El
cifrado del lado servidor con claves administradas por el cliente mejora en ADE al permitir el uso de cualquier tipo
de sistema operativo y de imágenes para las máquinas virtuales mediante el cifrado de datos en el servicio
Storage.
Pasos siguientes
¿Qué es Azure Key Vault?
Azure Premium Storage: diseño de alto rendimiento
Este artículo proporciona instrucciones para crear aplicaciones de alto rendimiento con Azure Premium
Storage. Puede usar las instrucciones proporcionadas en este documento junto con los procedimientos
recomendados de rendimiento aplicables a las tecnologías usadas por la aplicación. Para ilustrar las directrices,
hemos usado SQL Server en Premium Storage como ejemplo en este documento.
Si bien en este artículo se tratan los escenarios de rendimiento de la capa de almacenamiento, deberá optimizar
la capa de la aplicación. Por ejemplo, si hospeda una granja de SharePoint en Azure Premium Storage, puede
usar los ejemplos de SQL Server de este artículo para optimizar el servidor de bases de datos. Además,
optimice el servidor web y el servidor de aplicaciones de la granja de SharePoint para obtener el máximo
rendimiento.
Este artículo le ayudará a responder a las siguientes preguntas habituales acerca de cómo optimizar el
rendimiento de las aplicaciones en Azure Premium Storage:
¿Cómo medir el rendimiento de las aplicaciones?
¿Por qué no se ve el alto rendimiento esperado?
¿Qué factores influyen en el rendimiento de las aplicaciones en Premium Storage?
¿Cómo influyen estos factores en el rendimiento de las aplicaciones en Premium Storage?
¿Cómo puede optimizar para IOPS, el ancho de banda y la latencia?
Proporcionamos estas directrices específicamente para Premium Storage porque las cargas de trabajo que se
ejecutan en Premium Storage dependen mucho del rendimiento. Se proporcionan ejemplos donde
corresponda. También puede aplicar algunas de estas instrucciones a las aplicaciones que se ejecutan en
máquinas virtuales de IaaS con discos de Standard Storage.
NOTE
A veces, lo que parece ser un problema de rendimiento del disco es realmente un cuello de botella de red. En estos casos,
debería optimizarse el rendimiento de la red.
Si desea realizar pruebas comparativas de su disco, consulte nuestro artículo sobre cómo realizar pruebas comparativas
realizadas de un disco.
Si la VM admite redes aceleradas, debe asegurarse de que esta opción esté habilitada. Si no está habilitada, puede
habilitarla en VM ya implementadas, tanto en Windows como en Linux.
Antes de comenzar, si no está familiarizado con Premium Storage, lea primero los artículos ¿Qué tipos de disco
están disponibles en Azure? y Objetivos de escalabilidad y rendimiento de Azure Storage para cuentas de
almacenamiento.
Indicadores del rendimiento de las aplicaciones

Evaluamos si una aplicación tiene un buen rendimiento o no mediante indicadores de rendimiento como: la
rapidez con la que una aplicación procesa una solicitud del usuario, la cantidad de datos que una aplicación
procesa por solicitud, cuántas solicitudes procesa una aplicación en un determinado período, cuánto tiempo
tiene que esperar un usuario para obtener una respuesta después de enviar su solicitud. Los términos técnicos
para estos indicadores de rendimiento son IOPS, latencia y rendimiento o ancho de banda.
En esta sección, trataremos los indicadores de rendimiento comunes en el contexto de Premium Storage. En la
siguiente sección, Reunión de los requisitos de rendimiento de las aplicaciones, obtendrá información sobre
cómo medir estos indicadores de rendimiento de las aplicaciones. Más adelante, en Optimización del
rendimiento de las aplicaciones, obtendrá información acerca de los factores que afectan a estos indicadores de
rendimiento y recomendaciones para optimizarlos.
E/S
IOPS, o el número de operaciones de E/S por segundo, es el número de solicitudes que la aplicación envía a los
discos de almacenamiento en un segundo. Una operación de entrada y salida puede ser de lectura o escritura,
secuencial o aleatoria. Las aplicaciones de procesamiento de transacciones en línea (OLTP ), como un sitio web
de venta directa en línea, necesitan procesar muchas solicitudes de usuario simultáneas inmediatamente. Las
solicitudes de usuario suponen insertar y actualizar transacciones con un uso intensivo de las bases de datos y
que la aplicación debe procesar rápidamente. Por lo tanto, las aplicaciones OLTP requieren IOPS muy alta.
Dichas aplicaciones controlan millones de solicitudes de E/S pequeñas y aleatorias. Si tiene este tipo de
aplicación, debe diseñar la infraestructura de aplicaciones para optimizar la IOPS. En la sección siguiente,
Optimización del rendimiento de las aplicaciones, analizaremos en detalle todos los factores que debe tener en
cuenta para obtener una IOPS alta.
Cuando conecte un disco de Almacenamiento premium a la máquina virtual a gran escala, Azure aprovisiona
automáticamente un número garantizado de IOPS según la especificación del disco. Por ejemplo, un disco P50
aprovisiona 7500 IOPS. Cada tamaño de máquina virtual a gran escala también tiene un límite de IOPS
específico que puede admitir. Por ejemplo, una máquina virtual GS5 estándar tiene un límite de 80.000 IOPS.
Throughput
El rendimiento o ancho de banda es la cantidad de datos que la aplicación envía a los discos de almacenamiento
en un intervalo especificado. Si la aplicación está realizando operaciones de entrada y salida con tamaños de
unidad de E/S grandes, requiere un alto rendimiento. Las aplicaciones de almacenamiento de datos tienden a
emitir operaciones con un uso intensivo de análisis que acceden a grandes porciones de datos a la vez y suelen
llevar a cabo operaciones masivas. En otras palabras, estas aplicaciones requieren un mayor rendimiento. Si
tiene este tipo de aplicación, debe diseñar su infraestructura para optimizar el rendimiento. En la sección
siguiente, analizamos en detalle los factores que se deben optimizar para lograrlo.
Cuando conecte un disco de Premium Storage a una máquina virtual a gran escala, Azure aprovisiona el
rendimiento según la especificación del disco. Por ejemplo, un disco P50 aprovisiona 250 MB por capacidad de
proceso del segundo disco. Cada tamaño de máquina virtual a gran escala también tiene un límite de
rendimiento específico que puede admitir. Por ejemplo, la máquina virtual GS5 estándar tiene un rendimiento
máximo de 2.000 MB por segundo.
Hay una relación entre el rendimiento y el número de IOPS, tal como se muestra en la siguiente fórmula.
Por lo tanto, es importante determinar los valores óptimos de rendimiento y de IOPS que requiere una
aplicación. Si intenta optimizar uno, el otro también se ve afectado. En una sección posterior, Optimización del
rendimiento de las aplicaciones, trataremos con más detalle cómo optimizar el rendimiento y la IOPS.
Latencia
La latencia es el tiempo que tarda una aplicación en recibir una sola solicitud, enviarla a los discos de
almacenamiento y enviar la respuesta al cliente. Se trata de una medida crítica del rendimiento de una
aplicación, además de la IOPS y el rendimiento. La latencia de un disco de almacenamiento premium es el
tiempo que tarda en recuperar la información de una solicitud y comunicarla de nuevo a la aplicación. Premium
Storage proporciona latencias bajas coherentes. Los discos Premium están diseñados para proporcionar
latencias de milisegundos de un solo dígito en la mayoría de las operaciones de E/S. Si habilita el
almacenamiento en caché de host ReadOnly en discos de almacenamiento premium, puede obtener una
latencia de lectura mucho menor. Trataremos el almacenamiento en caché de disco con más detalle en la
sección Optimización del rendimiento de las aplicaciones.
Cuando se optimiza la aplicación para obtener un valor de IOPS y un rendimiento mayores, afectará a su
latencia. Después de ajustar el rendimiento de las aplicaciones, siempre se evalúa la latencia de la aplicación
para evitar un comportamiento inesperado con alta latencia.
Las siguientes operaciones de plano de control en Managed Disks pueden implicar el movimiento del disco de
una ubicación de almacenamiento a otra. Esto se orquesta mediante una copia en segundo plano de los datos
que puede tardar varias horas en completarse, normalmente menos de 24 horas en función de la cantidad de
datos en los discos. Durante ese tiempo, la aplicación puede experimentar una latencia de lectura más alta de lo
habitual, ya que algunas lecturas pueden redirigirse a la ubicación original y pueden tardar más tiempo en
completarse. No hay ningún impacto en la latencia de escritura durante este período.
Actualizar el tipo de almacenamiento.
Asociar o desasociar un disco de una VM a otra.
Crear un disco administrado a partir de un VHD.
Crear un disco administrado a partir de una instantánea.
Convertir discos no administrados en discos administrados.
Lista de comprobación del rendimiento de las aplicaciones

para los discos
El primer paso para diseñar aplicaciones de alto rendimiento que se ejecutan en Azure Premium Storage es
entender los requisitos de rendimiento de las aplicaciones. Después de reunir los requisitos de rendimiento,
puede optimizar la aplicación para lograr un rendimiento óptimo.
En la sección anterior, explicamos los indicadores de rendimiento comunes: IOPS, rendimiento y latencia. Debe
identificar cuál de estos indicadores de rendimiento son fundamentales para que la aplicación proporcione la
experiencia de usuario deseada. Por ejemplo, una IOPS alta es más importante para las aplicaciones OLTP que
procesan millones de transacciones en un segundo. Por otra parte, un alto rendimiento es fundamental para las
aplicaciones de Almacenamiento de datos que procesan grandes cantidades de datos en un segundo. Una
latencia extremadamente baja es fundamental para las aplicaciones en tiempo real, como sitios web de
streaming de vídeo en directo.
A continuación, mida los requisitos para obtener el máximo rendimiento de sus aplicaciones a lo largo de toda
su duración. Use la siguiente lista de comprobación de ejemplo como punto de partida. Registre los requisitos
para obtener el máximo rendimiento durante períodos de carga de trabajo normales, pico y valle. Al identificar
los requisitos para todos los niveles de carga de trabajo, podrá determinar los requisitos de rendimiento
generales de la aplicación. Por ejemplo, la carga de trabajo normal de un sitio web de comercio electrónico
serán las transacciones atendidas durante la mayoría de los días en un año. La carga de trabajo máxima del sitio
web serán las transacciones atendidas durante la temporada de vacaciones o eventos de ventas especiales. La
carga de trabajo máxima normalmente se experimenta durante un período limitado, pero puede que la
aplicación deba escalar su funcionamiento normal de dos o más veces. Descubra los requisitos de percentil 50,
percentil 90 y percentil 99. Esto ayuda a filtrar los valores atípicos en los requisitos de rendimiento, por lo que
puede centrar sus esfuerzos en optimizar para los valores correctos.
Lista de comprobación de requisitos de rendimiento de las

aplicaciones
REQUISITOS DE
RENDIMIENTO PERCENTIL 50 PERCENTIL 90 PERCENTIL 99
Máx. Transacciones por

segundo
Porcentaje de operaciones
de lectura
de escritura
aleatorias
secuenciales
Tamaño de las solicitudes

de E/S
Rendimiento medio
Máx. Throughput
Mín. Latencia
Latencia media
Máx. CPU
Promedio de CPU
Máx. Memoria
Promedio de memoria
Profundidad de la cola
NOTE
Debe considerar la posibilidad de escalar estos números en función del crecimiento futuro previsto de la aplicación. Es
buena idea para planificar el crecimiento antes de tiempo, porque podría ser más difícil cambiar la infraestructura para
mejorar el rendimiento más adelante.
Si tiene una aplicación existente y desea cambiar a Premium Storage, primero prepare la lista de comprobación
anterior para la aplicación existente. A continuación, cree un prototipo de la aplicación en Premium Storage y
diseñe la aplicación de acuerdo con las directrices descritas en Optimización del rendimiento de las aplicaciones
, en una sección posterior de este documento. En el siguiente artículo se describen las herramientas que puede
usar para recopilar las mediciones de rendimiento.
Contadores para medir los requisitos de rendimiento de las aplicaciones
La mejor forma de medir los requisitos de rendimiento de las aplicaciones es usar las herramientas de
supervisión del rendimiento proporcionadas por el sistema operativo del servidor. Puede usar PerfMon para
Windows e iostat para Linux. Estas herramientas capturan contadores correspondientes a cada medida
explicada en la sección anterior. Debe capturar los valores de estos contadores cuando la aplicación funciona
con cargas de trabajo normales, pico y valle.
Los contadores de rendimiento están disponibles para el procesador y la memoria, así como en cada disco
lógico y físico del servidor. Al usar discos de Almacenamiento premium con una máquina virtual, los
contadores del disco físico son para cada disco de Almacenamiento premium y los contadores del disco lógico
son para cada volumen creado en los discos de Almacenamiento premium. Debe capturar los valores de los
discos que hospedan la carga de trabajo de la aplicación. Si hay una asignación uno a uno entre los discos
lógicos y físicos, puede hacer referencia a los contadores del disco físico; de lo contrario, haga referencia a los
contadores del disco lógico. En Linux, el comando iostat genera un informe de uso de CPU y disco. El informe
de uso del disco proporciona estadísticas por cada dispositivo físico o partición. Si tiene un servidor de bases de
datos con sus datos y registros en discos independientes, recopile estos datos para ambos discos. En la tabla
siguiente se describen los contadores para discos, procesadores y memoria:
CONTADOR DESCRIPCIÓN PERFMON IOSTAT
E/S por segundo o Número de solicitudes de Lecturas de disco/s tps

transacciones por E/S emitidas en el disco de Escrituras en disco/s r/s
segundo almacenamiento por w/s
segundo.
Escrituras y lecturas de Porcentaje de operaciones % de tiempo de lectura de r/s

disco de lectura y escritura disco w/s
realizadas en el disco. % de tiempo de escritura de
disco
Rendimiento Cantidad de datos que se Bytes de lectura de disco/s kB_read/s

leen o escriben en el disco Bytes de escritura en kB_wrtn/s
por segundo. disco/s
Latency Tiempo total para Promedio de segundos de await

completar una solicitud de disco/lectura svctm
E/S del disco. Promedio de segundos de
disco/escritura
Tamaño de E/S El tamaño de E/S las Promedio de bytes de avgrq-sz

solicitudes en los discos de disco/lectura
almacenamiento. Promedio de bytes de
disco/escritura
Profundidad de la cola Número de solicitudes de Longitud actual de cola de avgqu-sz

E/S pendientes de lectura disco
de o escritura en el disco de
almacenamiento.
Máx. memoria Cantidad de memoria % de bytes confirmados en Use vmstat

necesaria para ejecutar la uso
aplicación sin problemas
Máx. CPU Cantidad de CPU necesaria % de tiempo de procesador %util

para ejecutar la aplicación
sin problemas
Obtenga más información sobre iostat y PerfMon.

Optimización del rendimiento de las aplicaciones
Los principales factores que influyen en el rendimiento de una aplicación que se ejecuta en Premium Storage
son la naturaleza de las solicitudes de E/S, el tamaño de la máquina virtual, el tamaño del disco, el número de
discos, la caché de disco, el multithreading y la profundidad de la cola. Puede controlar algunos de estos
factores con mecanismos proporcionados por el sistema. Es posible que la mayoría de las aplicaciones no le de
opción de modificar el tamaño de E/S y la profundidad de la cola directamente. Por ejemplo, si usa SQL Server,
no puede elegir la profundidad de la cola y el tamaño de E/S. SQL Server selecciona los valores de tamaño de
E/S y profundidad de la cola óptimos para obtener el máximo rendimiento. Es importante comprender los
efectos de ambos tipos de factores en rendimiento de su aplicación para poder aprovisionar los recursos
adecuados para satisfacer las necesidades de rendimiento.
En esta sección, consulte la lista de comprobación de los requisitos de la aplicación que creó para averiguar la
cantidad que necesita para optimizar el rendimiento de las aplicaciones. En función de ello, podrá determinar
qué factores de esta sección debe optimizar. Para ver los efectos de cada factor en el rendimiento de las
aplicaciones, ejecute las herramientas de pruebas comparativas en la configuración de su aplicación. Vea el
artículo Pruebas comparativas haciendo clic en el vínculo que aparece al final de este documento para conocer
los pasos para ejecutar las herramientas de pruebas comparativas comunes en las máquinas virtuales de
Windows y de Linux.
Optimización de IOPS, rendimiento y latencia de un vistazo
En la tabla siguiente se resumen los factores de rendimiento y los pasos necesarios para optimizar la IOPS, el
rendimiento y la latencia. Las secciones que siguen a este resumen describen cada factor con mucha más
profundidad.
Para obtener más información sobre los tamaños de máquina virtual y la IOPS, el rendimiento y la latencia
disponibles para cada tipo de máquina virtual, vea los tamaños de máquinas virtuales Linux o tamaños de
máquinas virtuales Windows.
E/S RENDIMIENTO LATENCY
Escenario de ejemplo Aplicación OLTP Aplicación de Aplicaciones casi en tiempo

empresarial que requiere Almacenamiento de datos real que requieren
una tasa muy alta de de empresa que procesa respuestas instantáneas a
transacciones por segundo. grandes cantidades de solicitudes de usuario, como
datos. juegos en línea.
Factores de rendimiento
Tamaño de E/S Un tamaño de E/S menor Un tamaño de E/S mayor

produce una mayor IOPS. produce un mayor
rendimiento.
Tamaño de VM Use un tamaño de máquina Use un tamaño de máquina Use un tamaño de máquina
virtual que ofrezca una virtual con un límite de virtual que ofrezca una
IOPS mayor que los rendimiento mayor que los escala de límites mayor que
requisitos de la aplicación. requisitos de la aplicación. los requisitos de la
aplicación.
Tamaño del disco Use un tamaño de disco Use un tamaño de disco Use un tamaño de disco
que ofrezca una IOPS con un límite de que ofrezca una escala de
mayor que los requisitos de rendimiento mayor que los límites mayor que los
la aplicación. requisitos de la aplicación. requisitos de la aplicación.
E/S RENDIMIENTO LATENCY
Máquina virtual y límites El límite de IOPS del El límite de rendimiento del Los límites de la escala del
de escala de disco tamaño de la máquina tamaño de la máquina tamaño de la máquina
virtual elegido debe ser virtual elegido debe ser virtual elegidos deben ser
mayor que la IOPS total mayor que el rendimiento mayores que los límites de
controlada por los discos de total controlado por los escala total de los discos de
almacenamiento premium discos de almacenamiento almacenamiento premium
conectados. premium conectados. conectados.
Almacenamiento en Habilite la caché de solo Habilite la caché de solo

caché de disco lectura en los discos de lectura en los discos de
almacenamiento premium almacenamiento premium
con operaciones intensivas con operaciones intensivas
de lectura para obtener una de lectura para obtener
mayor IOPS de lectura. latencias de lectura muy
bajas.
Seccionamiento del disco Use varios discos y

secciónelos conjuntamente
para conseguir un límite de
IOPS y rendimiento
combinado superior. El
límite combinado por
máquina virtual debe ser
mayor que los límites
combinados de los discos
premium conectados.
Tamaño de franja Un menor tamaño de franja Un mayor tamaño de franja

para un patrón de E/S para un patrón de E/
pequeño y aleatorio visto grande y secuencial visto en
en las aplicaciones OLTP. las aplicaciones de
Por ejemplo, puede usar un Almacenamiento de datos.
tamaño de franja de 64 KB Por ejemplo, puede usar un
para aplicaciones OLTP de tamaño de franja de 256 KB
SQL Server. para aplicaciones de
Almacenamiento de datos
de SQL Server.
Multithreading Use el multithreading para

insertar un mayor número
de solicitudes en Premium
Storage, lo que dará lugar a
una mayor IOPS y
rendimiento. Por ejemplo,
en SQL Server establezca
un valor MAXDOP alto para
asignar más CPU a SQL
Server.
Profundidad de la cola Una profundidad de la cola Una profundidad de la cola Una profundidad de la cola
mayor produce una IOPS mayor produce un mayor menor produce latencias
mayor. rendimiento. más bajas.
Naturaleza de las solicitudes de E/S

Una solicitud de E/S es una unidad de operación de entrada y salida que la aplicación va a realizar. La
identificación de la naturaleza de las solicitudes de E/S, aleatorias o secuenciales, lectura o escritura, pequeñas o
grandes, ayudará a determinar los requisitos de rendimiento de la aplicación. Es importante comprender la
naturaleza de las solicitudes de E/S para tomar las decisiones correctas al diseñar la infraestructura de las
aplicaciones. IOs se debe distribuir uniformemente para lograr el mejor rendimiento posible.
El tamaño de E/S es uno de los factores más importantes. El tamaño de E/S es el tamaño de la solicitud de
operación de entrada/salida generada por la aplicación. El tamaño de E/S tiene una repercusión considerable en
el rendimiento, especialmente en la IOPS y el ancho de banda que la aplicación es capaz de lograr. La fórmula
siguiente muestra la relación entre IOPS, tamaño de E/S y ancho de banda y rendimiento.
Algunas aplicaciones permiten modificar su tamaño de E/S, mientras que otras aplicaciones no lo permiten. Por
ejemplo, SQL Server determina el tamaño de E/S óptimo en sí; no proporciona a los usuarios ningún botón
para cambiarlo. Por otro lado, Oracle proporciona un parámetro llamado DB_BLOCK_SIZE con el que puede
configurar el tamaño de la solicitud de E/S de la base de datos.
Si usa una aplicación que no permite cambiar el tamaño de E/S, use las directrices de este artículo para
optimizar el KPI de rendimiento que es más importante para su aplicación. Por ejemplo,
Una aplicación OLTP genera millones de solicitudes de E/S pequeñas y aleatorias. Para controlar estos tipos
de solicitudes de E/S, debe diseñar la infraestructura de la aplicación para obtener una mayor IOPS.
Una aplicación de almacenamiento de datos genera solicitudes de E/S grandes y secuenciales. Para controlar
estos tipos de solicitudes de E/S, debe diseñar la infraestructura de la aplicación para obtener el mayor
ancho de banda o el rendimiento.
Si usa una aplicación que le permite cambiar el tamaño de E/S, use esta regla general para el tamaño de E/S,
además otras directrices de rendimiento.
Un tamaño de E/S menor para obtener una mayor IOPS. Por ejemplo, 8 KB para una aplicación OLTP.
Un tamaño de E/S mayor para obtener un mayor ancho de banda y rendimiento. Por ejemplo, 1024 KB para
una aplicación de Almacenamiento de datos.
Este es un ejemplo de cómo calcular la IOPS y el ancho de banda y el rendimiento de la aplicación. Considere
una aplicación con un disco P30. El máximo rendimiento/ancho de banda e IOPS que un disco P30 puede
lograr es 200 MB por segundo y 5000 IOPS respectivamente. Ahora, si la aplicación requiere la IOPS máxima
en el disco P30 y usa un tamaño de E/S más pequeño, como 8 KB, el ancho de banda resultante que podrá
obtener es de 40 MB por segundo. Sin embargo, si la aplicación requiere el máximo rendimiento/ancho de
banda del disco P30 y usa un tamaño de E/S mayor, como 1024 KB, el número de IOPS resultante será menor,
200 IOPS. Por consiguiente, ajuste el tamaño de E/S para que cumpla los requisitos de IOPS y ancho de banda
y rendimiento de la aplicación. En la siguiente tabla se resumen los distintos tamaños de E/S, así como sus
IOPS y rendimiento correspondientes para un disco P30.
RENDIMIENTO/ANCHO DE
REQUISITO DE LA APLICACIÓN TAMAÑO DE E/S E/S BANDA
IOPS máx. 8 KB 5.000 40 MB por segundo
Rendimiento máx. 1024 KB 200 200 MB por segundo
Rendimiento máx.+ IOPS 64 KB 3.200 200 MB por segundo

alta
IOPS máx. + alto 32 KB 5.000 160 MB por segundo

rendimiento
Para obtener una IOPS y un ancho de banda mayores que el valor máximo de un solo disco de
almacenamiento premium, use varios discos premium seccionados conjuntamente. Por ejemplo, seccione dos
discos P30 para obtener una IOPS combinada de 10.000 IOPS o un rendimiento combinado de 400 MB por
segundo. Como se explica en la sección siguiente, debe usar un tamaño de máquina virtual que admita la IOPS
y el rendimiento de disco combinados.
NOTE
a medida que aumente la IOPS o el rendimiento, el otro también aumenta, asegúrese de que no supera los límites de
IOPS o rendimiento del disco o la máquina virtual al aumentar cualquiera de ellos.
Para ver los efectos del tamaño de E/S en el rendimiento de las aplicaciones, puede ejecutar las herramientas de
pruebas comparativas en la máquina virtual y los discos. Cree varias ejecuciones de pruebas y use un tamaño
de E/S diferente para cada ejecución para ver el impacto. Consulte el artículo Pruebas comparativas, cuyo
vínculo aparece al final de este documento, para obtener más detalles.
Tamaños de máquina virtual a gran escala

Al empezar a diseñar una aplicación, una de las primeras cosas que hay que hacer es elegir una máquina virtual
para hospedar la aplicación. Premium Storage viene con tamaños de máquina virtual a gran escala que pueden
ejecutar aplicaciones que requieren una mayor capacidad de proceso y un alto rendimiento de E/S del disco
local Estas máquinas virtuales proporcionan procesadores más rápidos, una mayor proporción de memoria a
núcleo y una unidad de estado sólido (SSD ) para el disco local. Algunos ejemplos de máquinas virtuales a gran
escala que admiten Premium Storage son las de las series DS, DSv2 y GS.
Las máquinas virtuales a gran escala están disponibles en distintos tamaños con un número diferente de
núcleos de CPU, memoria, sistema operativo y tamaño del disco temporal. Cada tamaño de máquina virtual
también tiene el número máximo de discos de datos que se puede conectar a la máquina virtual. Por lo tanto, el
tamaño de máquina virtual seleccionado afectará al procesamiento, la memoria y la capacidad de
almacenamiento que están disponibles para su aplicación. También afecta al proceso y los costos de
almacenamiento. Por ejemplo, a continuación se proporcionan las especificaciones del mayor tamaño de
máquina virtual en una serie DS, una serie DSv2 y una serie GS:
LÍMITES DE
E/S DE LA
MEMORIA
TAMAÑOS MÁX. TAMAÑO DE CACHÉ DE
TAMAÑO DE NÚCLEOS DE DE DISCO DE DISCOS DE MEMORIA ANCHO DE
VM CPU MEMORIA VM DATOS CACHÉ E/S BANDA
Standard_D 16 112 GB OS = 1.023 32 576 GB 50.000 E/S 4.000 IOPS

S14 GB por y 33 MB
SSD Local segundo por
= 224 GB 512 MB segundo
por
segundo
Standard_G 32 448 GB OS = 1.023 64 4224 GB 80.000 E/S 5.000 IOPS

S5 GB por y 50 MB
SSD Local segundo por
= 896 GB 2000 MB segundo
por
segundo
Para ver una lista completa de todos los tamaños disponibles de máquina virtual de Azure, consulte el artículo
sobre tamaños de las máquinas virtuales Windows o tamaños de las máquinas virtuales Linux. Elija un tamaño
de máquina virtual que puede cumplir y escale a los requisitos de rendimiento de las aplicaciones que desee.
Además, tenga en cuenta que debe seguir consideraciones importantes al elegir los tamaños de las máquinas
virtuales.
Límites de escala
Los límites máximos de IOPS por máquina virtual y por disco son diferentes e independientes entre sí.
Asegúrese de que la aplicación mantiene la IOPS dentro de los límites de la máquina virtual, así como los
discos de premium conectados a ella. En caso contrario, el rendimiento de las aplicaciones experimentará una
limitación.
Por ejemplo, suponga que el requisito de la aplicación es un máximo de 4.000 IOPS. Para lograrlo, aprovisiona
un disco P30 en una máquina virtual DS1. El disco P30 puede proporcionar hasta 5.000 IOPS. Sin embargo, la
máquina virtual DS1 está limitada a 3.200 IOPS. Por consiguiente, el rendimiento de las aplicaciones estará
limitado a 3.200 IOPS por el límite de la máquina virtual y el rendimiento disminuirá. Para evitar esta situación,
elija un tamaño de máquina virtual y de disco que cumplan los requisitos de la aplicación.
Costo de operación
En muchos casos, es posible que el costo general de operación con Premium Storage sea inferior al uso de
Standard Storage.
Por ejemplo, considere una aplicación que requiere más de 16.000 IOPS. Para obtener este rendimiento,
necesitará una VM IaaS de Azure Standard_D14, que puede proporcionar una IOPS máxima de 16.000 con 32
discos de 1 TB de almacenamiento estándar. Cada disco de almacenamiento estándar de 1 TB puede alcanzar
un máximo de 500 IOPS. El costo estimado de esta máquina virtual por mes será de 1.570 USD. El costo
mensual de 32 discos de almacenamiento estándar será de 1.638 USD. El costo mensual total estimado será de
3.208 USD.
Sin embargo, si hospeda la misma aplicación en Premium Storage, necesitará un tamaño de máquina virtual
menor y menos discos de Premium Storage, lo que reduce el costo total. Una VM Standard_DS13 puede
cumplir los requisitos de 16.000 IOPS con cuatro discos P30. La máquina virtual DS13 tiene un máximo de
25.600 IOPS y cada disco P30 tiene un máximo de 5.000 IOPS. En general, esta configuración puede lograr
5.000 x 4 = 20.000 IOPS. El costo estimado de esta máquina virtual al mes será de 1.003 USD. El costo
mensual de cuatro discos P30 de almacenamiento Premium será de 544,34 USD. El costo mensual total
estimado será de 1,544 USD.
La tabla siguiente resume el análisis de costos de este escenario de Premium Storage y estándar.
ESTÁNDAR PREMIUM
Costo de máquina virtual al mes 1570,58 USD (Standard_D14) 1003,66 USD (Standard_DS13)
Costo de discos al mes 1638,40 USD (32 discos x 1 TB) 544,34 USD (4 discos x P30)
Costo total al mes 3.208,98 USD 1.544,34 USD
Linux Distros
Con Azure Premium Storage, obtendrá el mismo nivel de rendimiento para las máquinas virtuales de Windows
y de Linux. Se admiten muchas versiones de las distribuciones de Linux; puede ver la lista completa aquí. Es
importante tener en cuenta que son adecuadas distintas distribuciones para diferentes tipos de carga de
trabajo. Podrá ver diferentes niveles de rendimiento según la distribución en la que se ejecuta la carga de
trabajo. Pruebe las distribuciones de Linux con su aplicación y elija la que mejor se adapte.
Cuando ejecute Linux con Premium Storage, compruebe las actualizaciones más recientes acerca de los
controladores necesarios para garantizar un alto rendimiento.
Tamaños de disco de Premium Storage

Azure Premium Storage ofrece varios tamaños, con el fin de que elija el que mejor se adapte a sus necesidades.
Cada tamaño de disco tiene un límite de escala diferente de IOPS, ancho de banda y almacenamiento. Elija el
tamaño de disco de Premium Storage adecuado según los requisitos de la aplicación y el tamaño de la máquina
virtual a gran escala. En la tabla siguiente se muestran los tamaños de disco y sus capacidades. Los tamaños de
disco P4, P6, P15, P60, P70 y P80 solo se admiten actualmente para Managed Disks.
TA
MA
ÑOS
DE
SSD
PRE
MIU
Tam 4 8 16 32 64 128 256 512 102 2 4 819 16 32

año 4 048 096 2 384 767
de
disc
o
en
GiB
IOP 120 120 120 120 240 500 110 2,3 5.0 750 750 16 18 20.
S 0 00 00 0 0 000 000 000
por
disc
o
Ren 25 25 25 25 50 100 125 150 200 250 250 500 750 900
dim MiB MiB MiB MiB MiB Mi Mi MiB Mi Mi Mi Mi Mi Mi
ient /s /s /s /s /s B/s B/s /s B/s B/s B/s B/s B/s B/s
o
de
disc
o.
Má 350 350 350 350 350 350 350 350

xim 0 0 0 0 0 0 0 0
o
de
IOP
S
de
ráfa
ga
por
disc
o**
Ren 170 170 170 170 170 170 170 170

dim Mi Mi Mi Mi Mi Mi Mi Mi
ient B/s B/s B/s B/s B/s B/s B/s B/s
o
máx
imo
de
ráfa
ga
por
disc
o**
TA
MA
ÑOS
DE
SSD
PRE
MIU
Dur 30 30 30 30 30 30 30 30
n
máx
ima
de
ráfa
ga*
*
**Indica una característica que se encuentra actualmente en versión preliminar; consulte Envío de ráfagas en
disco para más información.
El número de discos que elija depende del tamaño de disco elegido. Puede usar un único disco P50 o varios
discos P10 para cubrir los requisitos de la aplicación. Tenga en cuenta las consideraciones enumeradas a
continuación al realizar su elección.
Límites de escala (IOPS y rendimiento )
Los límites de IOPS y rendimiento del tamaño de cada disco Premium son diferentes e independientes de los
límites de escala de la máquina virtual. Asegúrese de que la IOPS y el rendimiento totales de los discos están
dentro de los límites de escala del tamaño de máquina virtual elegido.
Por ejemplo, si un requisito de la aplicación es un máximo de 250 MB/s de rendimiento y usa una máquina
virtual DS4 con un solo disco P30. La máquina virtual DS4 puede proporcionar un máximo rendimiento de
256 MB/s. Sin embargo, un solo disco P30 tiene un límite de rendimiento de 200 MB por segundo. Por lo tanto,
la aplicación se restringirá a 200 MB/s debido al límite de disco. Para superar este límite, aprovisione más de un
disco de datos para la máquina virtual o cambie el tamaño de los discos a P40 o P50.
NOTE
Las lecturas atendidas por la caché no se incluyen en la IOPS y el rendimiento del disco, por lo que no están sujetas a los
límites del disco. La caché tiene su límite de IOPS y rendimiento independiente de la máquina virtual.
Por ejemplo, inicialmente sus lecturas y escrituras son 60MB/s y 40MB/s respectivamente. Con el tiempo, la memoria
caché se prepara y atiende cada vez más y más lecturas de la memoria caché. Entonces, puede obtener un mayor
rendimiento de escritura desde el disco.
Número de discos
Para determinar el número de discos que necesitará, evalúe los requisitos de la aplicación. Cada tamaño de
máquina virtual también tiene un límite en el número de discos que puede conectar a la máquina virtual.
Normalmente, es dos veces el número de núcleos. Asegúrese de que el tamaño de la máquina virtual que elija
puede admitir el número de discos necesario.
Recuerde que los discos de Premium Storage tienen capacidades de rendimiento superiores en comparación
con los discos de Standard Storage. Por tanto, si va a migrar la aplicación de la máquina virtual IaaS de Azure
Standard Storage a Premium Storage, probablemente necesitará menos discos premium para conseguir un
rendimiento igual o superior para la aplicación.
Almacenamiento en caché de disco
Las máquinas virtuales a gran escala que aprovechan Azure Premium Storage tienen una tecnología de
almacenamiento en caché de niveles múltiples denominada BlobCache. BlobCache usa una combinación de la
RAM de máquina virtual y SSD local para almacenar en caché. Esta memoria caché está disponible para los
discos de Premium Storage persistentes y los discos locales de la máquina virtual. De forma predeterminada,
esta configuración de la caché se establece en lectura y escritura para los discos del sistema operativo y de solo
lectura para los discos de datos hospedados en Premium Storage. Con la caché de disco habilitada en los discos
de Premium Storage, la máquinas virtuales a gran escala pueden lograr niveles de rendimiento
extremadamente altos que superan el rendimiento del disco subyacente.
WARNING
No se admite el almacenamiento en caché de disco para discos de 4 TiB o más. Si varios discos están conectados a la
máquina virtual, cada disco de menos de 4 TiB será compatible con el almacenamiento en caché.
Al cambiar la configuración de caché de un disco de Azure, se desconecta y se vuelve a conectar el disco de destino. Si se
trata del disco del sistema operativo, se reinicia la máquina virtual. Detenga todas las aplicaciones y todos los servicios
que podrían verse afectados por esta interrupción antes de cambiar la configuración de caché de disco.
Para más información acerca del funcionamiento de BlobCache, consulte la publicación de blog Azure Premium
Storage.
Es importante habilitar la memoria caché en el conjunto de discos correcto. Si debe habilitar el almacenamiento
en caché de disco en un disco de premium o no dependerá del patrón de la carga de trabajo que el disco
manejará. La tabla siguiente muestra el valor predeterminado de las opciones de caché para discos del sistema
operativo y datos.
TIPO DE DISCO CONFIGURACIÓN DE LA MEMORIA CACHÉ PREDETERMINADA
Disco del sistema operativo ReadWrite
Disco de datos ReadOnly
A continuación se muestra la configuración de caché de disco recomendada para los discos de datos:
CONFIGURACIÓN DEL ALMACENAMIENTO EN CACHÉ DE DISCO RECOMENDACIÓN SOBRE CUÁNDO USAR ESTA CONFIGURACIÓN
None Configure la caché de host como Ninguno para los discos de

solo escritura y con escritura intensiva.
ReadOnly Configure la caché de host como ReadOnly para discos de

solo lectura y lectura y escritura.
ReadWrite Configure la caché de host como ReadWrite solo si la

aplicación maneja correctamente la escritura de datos en
caché a discos persistentes cuando es necesario.
ReadOnly
Mediante la configuración del almacenamiento en caché ReadOnly en discos de datos de Premium Storage,
puede lograr una baja latencia de lectura y obtener una IOPS de lectura y un rendimiento de la aplicación muy
altos. Esto se debe a dos razones:
1. Las lecturas realizadas desde la memoria caché, que se encuentra en la memoria de la máquina virtual y el
SSD local, son mucho más rápidas que las lecturas desde el disco de datos, que se encuentra en el
almacenamiento de blobs de Azure.
2. Premium Storage no cuenta las lecturas que se atienden desde la caché para la IOPS y el rendimiento del
disco. Por lo tanto, la aplicación es capaz de lograr una IOPS y un rendimiento totales mayores.
ReadWrite
De forma predeterminada, los discos del sistema operativo tienen habilitada la caché ReadWrite. Recientemente
hemos agregado también compatibilidad para el almacenamiento en caché ReadWrite en los discos de datos. Si
usa el almacenamiento en caché ReadWrite, debe tener una manera adecuada de escribir los datos de la
memoria caché en discos persistentes. Por ejemplo, SQL Server administra por sí mismo la escritura de los
datos en caché en los discos de almacenamiento persistentes. El uso de la memoria caché ReadWrite con una
aplicación que no administre la persistencia de los datos necesarios puede provocar la pérdida de los datos, si
se bloquea la máquina virtual.
None
Actualmente, None solo se admite en discos de datos. No se admite en discos del SO. Si establece None en un
disco del sistema operativo, se invalidará internamente y se establecerá en ReadOnly.
Por ejemplo, puede aplicar estas directrices a un SQL Server que funciona en Premium Storage del modo
siguiente:
1. Configure la caché "ReadOnly" de los discos de Premium Storage que hospedan archivos de datos.
a. Las rápidas lecturas de la caché reducen el tiempo de consulta de SQL Server, ya que las páginas de datos
se recuperan mucho más rápido de la memoria caché que directamente desde los discos de datos.
b. Atender las lecturas de la caché significa que hay un rendimiento adicional de los discos de datos
premium. SQL Server puede usar este rendimiento adicional para recuperar más páginas de datos y otras
operaciones, como copia de seguridad/restauración, cargas por lotes y volver a generar un índice.
2. Configure la caché "None" en los discos de Premium Storage que hospedan los archivos de registro.
a. Los archivos de registro tienen sobre todo muchas operaciones de escritura. Por lo tanto, no se benefician
de la caché ReadOnly.
Optimización del rendimiento en máquinas virtuales Linux

Para todos los discos ultra o SSD Premium con la memoria caché establecida en ReadOnly o None, debe
deshabilitar las "barreras" cuando monte el sistema de archivos. En este escenario no se necesitan barreras, ya
que las operaciones de escritura en los discos de Premium Storage son duraderas para esta configuración de la
caché. Cuando la solicitud de escritura se completa correctamente, los datos están escritos en el
almacenamiento permanente. Para deshabilitar las "barreras", utilice uno de los siguientes métodos. Elija uno
para el sistema de archivos:
Para reiserFS, para deshabilitar las barreras, utilice la opción de montaje barrier=none . (Para habilitar las
barreras, use barrier=flush ).
Para ext3/ext4,, para deshabilitar las barreras, utilice la opción de montaje barrier=0 . (Para habilitar las
barreras, use barrier=1 ).
Para XFS, para deshabilitar las barreras, utilice la opción de montaje nobarrier . (Para habilitar las barreras,
use barrier ).
Para los discos de Premium Storage con la caché establecida en ReadWrite, habilite las barreras para la
durabilidad de escritura.
Para que las etiquetas de volumen persistan después de reiniciar la VM, debe actualizar /etc/fstab con las
referencias del identificador único universal (UUID ) en los discos. Para más información, vea Adición de un
disco administrado a una máquina virtual Linux.
Las distribuciones de Linux siguientes han sido validadas para discos SSD. Para mejorar el rendimiento y la
estabilidad con los discos SSD, se recomienda actualizar las máquinas virtuales a una de estas versiones o a
una versión más reciente.
Algunas de las versiones requieren Linux Integration Services (LIS ) v4.0 para Azure. Para descargar e instalar
una distribución, siga el vínculo que aparece en la tabla siguiente. Agregamos imágenes a la lista cuando se
completa la validación. Nuestras validaciones muestran que el rendimiento varía en cada imagen. El
rendimiento depende en las características de carga de trabajo y la configuración de la imagen. Se ajustan
diferentes imágenes a los distintos tipos de cargas de trabajo.
DISTRIBUCIÓN VERSIÓN KERNEL COMPATIBLE DETALLES
Ubuntu 12.04 o más reciente 3.2.0-75.110+ Ubuntu-12_04_5-LTS-

amd64-server-20150119-
en-us-30GB
Ubuntu 14.04 o más reciente 3.13.0-44.73+ Ubuntu-14_04_1-LTS-

amd64-server-20150123-
en-us-30GB
Debian 7.x, 8.x o más reciente 3.16.7-ckt4-1+
SUSE SLES 12 o más reciente 3.12.36-38.1+ suse-sles-12-priority-

v20150213
suse-sles-12-v20150213
SUSE SLES 11 SP4 o más reciente 3.0.101-0.63.1+
CoreOS 584.0.0+ o más reciente 3.18.4+ CoreOS 584.0.0
CentOS 6.5, 6.6, 6.7, 7.0 o más LIS4 requerido

reciente Vea la nota en la siguiente
sección
CentOS 7.1+ o más reciente 3.10.0-229.1.2.el7+ LIS4 recomendado

Vea la nota en la siguiente
sección
Red Hat Enterprise Linux 6.8+, 7.2+ o más reciente

(RHEL)
Oracle 6.0+, 7.2+ o más reciente UEK4 o RHCK
Oracle 7.0-7.1 o más reciente UEK4 o RHCK conLIS 4.1+
Oracle 6.4-6.7 o más reciente UEK4 o RHCK conLIS 4.1+
Controladores de LIS para CentOS Openlogic

Si tiene máquinas virtuales de OpenLogic CentOS, ejecute el comando siguiente para instalar a los
controladores más recientes:
sudo rpm -e hypervkvpd ## (Might return an error if not installed. That's OK.)
sudo yum install microsoft-hyper-v
Para activar los nuevos controladores, reinicie la máquina virtual.
Seccionamiento del disco

Cuando una máquina virtual a gran escala esté conectada a varios discos persistente almacenamiento
premium, los discos se pueden seccionar conjuntamente para agregar sus IOPS, ancho de banda y capacidad
de almacenamiento.
En Windows, puede usar espacios de almacenamiento para seccionar discos conjuntamente. Debe configurar
una columna para cada disco de un grupo. De lo contrario, el rendimiento general del volumen seccionado
puede ser inferior al esperado debido a una distribución desigual del tráfico entre los discos.
Importante: Con la UI del Administrador del servidor, puede establecer el número total de columnas hasta en 8
para un volumen seccionado. Al conectar más de ocho discos, use PowerShell para crear el volumen. Mediante
PowerShell, puede establecer un número de columnas igual al número de discos. Por ejemplo, si hay 16 discos
en un solo conjunto de secciones; especifique 16 columnas en el parámetro NumberOfColumns del cmdlet de
PowerShell New -VirtualDisk.
En Linux, use la utilidad MDADM para seccionar discos conjuntamente. Para ver los pasos detallados sobre
cómo seccionar discos en Linux, consulte Configuración del software RAID en Linux.
Tamaño de franja
Una configuración importante en el seccionamiento del disco es el tamaño de franja. El tamaño de franja o
tamaño de bloque es el fragmento de datos más pequeño que la aplicación puede manejar en un volumen
seccionado. El tamaño de franja que configurar depende del tipo de aplicación y su patrón de solicitudes. Si elije
un tamaño de franja incorrecto, podría provocar la desalineación de E/S, lo que conduce a una disminución del
rendimiento de la aplicación.
Por ejemplo, si una solicitud de E/S generada por la aplicación es mayor que el tamaño de franja del disco, el
sistema de almacenamiento escribe a través de límites de la unidad de franja en más de un disco. Cuando llega
el momento para tener acceso a esos datos, tendrá que buscar en las unidades con más de una franja para
completar la solicitud. El efecto acumulativo de este comportamiento puede provocar una degradación del
rendimiento considerable. Por otro lado, si el tamaño de la solicitud de E/S es menor que el tamaño de franja, y
si es aleatoria por naturaleza, las solicitudes de E/S pueden acumularse en el mismo disco, causar un cuello de
botella y, en última instancia, degradar el rendimiento de E/S.
Según el tipo de carga de trabajo que se ejecute la aplicación, elija un tamaño de franja adecuado. Para
solicitudes de E/S pequeñas aleatorias, use un tamaño de franja más pequeño. Por otra parte, para solicitudes
de E/S secuenciales grandes, use un tamaño de franja mayor. Descubra las recomendaciones de tamaño de
franja para la aplicación que se ejecutará en Premium Storage. Para SQL Server, configure el tamaño de franja
de 64 KB para cargas de trabajo OLTP y de 256 KB para cargas de trabajo de almacenamiento de datos. Vea
Procedimientos recomendados para SQL Server en máquinas virtuales de Azure para más información.
NOTE
Puede seccionar conjuntamente un máximo de 32 discos de almacenamiento premium en una serie de máquinas
virtuales DS y 64 discos de almacenamiento premium en una serie de máquinas virtuales GS.
Multithreading
Azure ha diseñado la plataforma Premium Storage para ser enormemente paralela. Por lo tanto, una aplicación
multiproceso logra un rendimiento mucho mayor que una aplicación uniproceso. Una aplicación multiproceso
divide sus tareas en varios subprocesos y aumenta la eficacia de su ejecución mediante el uso de los recursos
de la máquina virtual y el disco al máximo.
Por ejemplo, si la aplicación se ejecuta en una máquina virtual de un solo núcleo que usa dos subprocesos, la
CPU puede cambiar entre los dos subprocesos para lograr la eficiencia. Mientras un subproceso está esperando
que se complete la E/S del disco, la CPU puede cambiar a otro subproceso. De esta manera, dos subprocesos
pueden lograr más que un único subproceso. Si la máquina virtual tiene más de un núcleo, reduce aún más el
tiempo de ejecución, ya que cada núcleo puede ejecutar tareas en paralelo.
No puede cambiar la forma en que una aplicación comercial implementa uniprocesos o multi-threading. Por
ejemplo, SQL Server es capaz de manejar varios núcleos y CPU. Sin embargo, SQL Server determina en qué
condiciones aprovechará uno o varios subprocesos para procesar una consulta. Puede ejecutar consultas y
generar los índices mediante el multi-threading. Para una consulta que implica combinar tablas grandes y
ordenar los datos antes de devolverlos al usuario, SQL Server probablemente usará varios subprocesos. Sin
embargo, un usuario no puede controlar si SQL Server se ejecuta una consulta con un único subproceso o
varios subprocesos.
Hay opciones de configuración que puede modificar para tener en cuenta este multi-threading o el
procesamiento en paralelo de una aplicación. Por ejemplo, en el caso de SQL Server es la configuración con el
máximo grado de paralelismo. Esta configuración, denominada MAXDOP, permite configurar el número
máximo de procesadores que puede usar SQL Server cuando realiza el procesamiento en paralelo. Puede
configurar MAXDOP para consultas individuales u operaciones de índice. Resulta especialmente útil cuando
desea equilibrar los recursos del sistema para una aplicación crítica para el rendimiento.
Por ejemplo, supongamos que su aplicación con SQL Server ejecuta una consulta de gran tamaño y una
operación de índice al mismo tiempo. Supongamos que desea que la operación de índice sea más eficaz en
comparación con la consulta de gran tamaño. En tal caso, puede establecer el valor de MAXDOP de la
operación de índice para que sea mayor que el valor de MAXDOP para la consulta. De este modo, SQL Server
tiene un mayor número de procesadores que puede aprovechar para la operación de índice en comparación
con el número de procesadores que puede dedicar a la consulta de gran tamaño. Recuerde que no controla el
número de subprocesos que SQL Server usará para cada operación. Puede controlar el número máximo de
procesadores que se dedicó a multi-threading.
Obtenga más información sobre Grados de paralelismo en SQL Server. Descubra la configuración que influye
en el multi-threading en la aplicación y sus configuraciones para optimizar el rendimiento.
Profundidad de la cola
La profundidad de la cola, la longitud de la cola o el tamaño de la cola es el número de solicitudes de E/S
pendientes en el sistema. El valor de la profundidad de la cola determina cuántas operaciones de E/S, que
procesarán los discos de almacenamiento, puede alinear la aplicación. Afecta a los tres indicadores de
rendimiento de las aplicaciones que analizamos en este artículo: IOPS, rendimiento y latencia.
La profundidad de la cola y multi-threading están estrechamente relacionados. El valor de la profundidad de la
cola indica el número de multi-threading que puede lograrse mediante la aplicación. Si la profundidad de la
cola es grande, la aplicación puede ejecutar más operaciones simultáneamente, es decir, más multi-threading. Si
la profundidad de la cola es pequeña, incluso si la aplicación es multiproceso, no tendrá suficientes solicitudes
alineadas para la ejecución simultánea.
Normalmente, las aplicaciones comerciales no le permiten cambiar la profundidad de la cola, porque si se
establece incorrectamente, hará más daño que beneficio. Las aplicaciones establecerán el valor correcto de
profundidad de la cola para obtener un rendimiento óptimo. Sin embargo, es importante entender este
concepto, para que pueda solucionar problemas de rendimiento con la aplicación. También puede observar los
efectos de profundidad de la cola mediante la ejecución de herramientas de pruebas comparativas del sistema.
Algunas aplicaciones proporcionan opciones para influir en la profundidad de la cola. Por ejemplo, la
configuración de MAXDOP (grado máximo de paralelismo) en SQL Server se explicó en la sección anterior.
MAXDOP es una forma de influir en la profundidad de la cola y el multi-threading, aunque no cambia
directamente el valor de Profundidad de la cola de SQL Server.
Profundidad de cola alta
Una profundidad de la cola alta alinea más operaciones en el disco. El disco conoce la siguiente solicitud de su
cola de antemano. Por lo tanto, el disco puede programar las operaciones de antemano y procesarlas en una
secuencia óptima. Puesto que la aplicación está enviando solicitudes más al disco, el disco puede procesar más
E/S paralelas. En última instancia, la aplicación podrá lograr una mayor IOPS. Puesto que la aplicación está
procesando más solicitudes, también aumenta el rendimiento total de la aplicación.
Normalmente, una aplicación puede lograr un rendimiento máximo con 8-16+ E/S pendientes para cada disco
conectado. Si la profundidad de la cola es uno, la aplicación no inserta suficientes E/S en el sistema y procesará
menos cantidad en un período determinado. En otras palabras, menor rendimiento.
Por ejemplo, en SQL Server, si se establece el valor de MAXDOP en una consulta en "4", se informa a SQL
Server de que puede usar un máximo de cuatro núcleos para ejecutar la consulta. SQL Server determinará el
mejor valor de profundidad de la cola y el número de núcleos para la ejecución de la consulta.
Profundidad de la cola óptima
Un valor de profundidad de la cola muy alto también tiene sus inconvenientes. Si el valor de profundidad de la
cola es demasiado alto, la aplicación intentará manejar una IOPS muy alta. A menos que la aplicación tiene
discos persistentes con suficientes IOPS aprovisionada, esto puede afectar negativamente a las latencias de la
aplicación. La siguiente fórmula muestra la relación entre la E/S por segundo, la latencia y la profundidad de la
cola.
No debe configurar la profundidad de la cola en cualquier valor alto, sino en un valor óptimo, que puede
ofrecer suficientes IOPS para la aplicación sin afectar a las latencias. Por ejemplo, si la latencia de la aplicación
debe ser 1 milisegundo, la profundidad de la cola necesaria para lograr 5.000 IOPS es QD = 5000 x 0,001 = 5.
Profundidad de la cola para un volumen seccionado
Para un volumen seccionado, mantenga una profundidad de la cola lo suficientemente alta para que cada disco
tenga una profundidad de la cola máxima individual. Por ejemplo, imagine una aplicación que inserta una
profundidad de cola de 2 y hay cuatro discos en la franja. Las dos solicitudes de E/S irán a dos discos y los dos
discos restantes estarán inactivos. Por lo tanto, configure la profundidad de la cola de modo que todos los
discos puedan estar ocupados. La siguiente fórmula muestra cómo determinar la profundidad de la cola de
volúmenes seccionados.
Limitaciones
Azure Premium Storage aprovisiona un número especificado de IOPS y rendimiento de acuerdo con los
tamaños de la máquina virtual y de disco que elija. Cada vez que la aplicación intenta que la IOPS o el
rendimiento estén por encima de los límites que puede administrar la máquina virtual o el disco, Premium
Storage lo limitará. Esto se manifiesta en forma de una disminución del rendimiento de la aplicación. Esto
puede significar una latencia mayor, un rendimiento menor o una IOPS menor. Si Premium Storage no lo
limita, la aplicación podría fallar completamente al exceder lo que sus recursos son capaces de conseguir. Por lo
tanto, para evitar problemas de rendimiento debido a la limitación, aprovisione siempre suficientes recursos
para su aplicación. Tenga en cuenta lo que hemos explicado en las secciones anteriores sobre los tamaños de la
máquina virtual y el disco. Las pruebas comparativas son la mejor forma de averiguar qué recursos necesitará
para hospedar su aplicación.
Pasos siguientes
Si desea realizar pruebas comparativas de su disco, consulte nuestro artículo sobre cómo realizar pruebas
comparativas realizadas de un disco.
Más información sobre los tipos de disco disponibles: Selección de un tipo de disco
Para los usuarios de SQL Server, lea artículos sobre procedimientos recomendados para SQL Server:
Procedimientos recomendados para SQL Server en Azure Virtual Machines
Azure Premium Storage proporciona el máximo rendimiento para SQL Server en una máquina virtual de
Azure
Seguridad de SSD Premium
Los discos SSD Premium admiten la ampliación en cualquier tamaño de disco <= 512 GiB (P20 o inferior). Estos
tamaños de disco admiten la ampliación en la medida de lo posible y usan un sistema de crédito para
administrarla. Los créditos se acumulan en un cubo de ráfagas siempre que el tráfico del disco está por debajo del
objetivo de rendimiento aprovisionado para el tamaño del disco, y consume créditos cuando el tráfico supera el
objetivo. Se realiza un seguimiento del tráfico contra IOPS y el ancho de banda en el objetivo aprovisionado.
La ampliación del disco está habilitada de forma predeterminada en las nuevas implementaciones de los tamaños
del disco que la admiten. Los tamaños del disco existentes, si admiten la ampliación del disco, pueden habilitar la
seguridad a través de cualquiera de los métodos siguientes:
Desconecte el disco y vuelva a conectarlo.
Detenga e inicie la VM.
Estados de ráfaga
Todos los tamaños de disco aplicables de la ráfaga comenzarán con un cubo de crédito de ráfaga completo cuando
el disco esté conectado a una máquina virtual. La duración máxima de la ampliación viene determinada por el
tamaño del cubo de crédito de ráfaga. Solo se pueden acumular créditos no usados hasta el tamaño del cubo de
crédito. En cualquier momento, el cubo de crédito de ráfaga del disco puede estar en uno de los tres estados
siguientes:
Acumulación, cuando el tráfico del disco usa menos del objetivo de rendimiento aprovisionado. Puede
acumular crédito si el tráfico del disco es superior a los objetivos de IOPS o ancho de banda, o de ambos.
Todavía puede acumular créditos de E/S si está consumiendo ancho de banda del disco completo, y
viceversa.
Rechazo, cuando el tráfico del disco usa más del objetivo de rendimiento aprovisionado. El tráfico de ráfaga
consumirá créditos de IOPS o ancho de banda de forma independiente.
Constante restante, cuando el tráfico del disco se encuentra exactamente en el objetivo de rendimiento
aprovisionado.
En la tabla siguiente se resumen los tamaños del disco que proporcionan compatibilidad con la ampliación y las
especificaciones de ráfaga.
Disponibilidad regional
Actualmente, la ampliación del disco solo está disponible en la región Centro-oeste de EE. UU.
Tamaños de disco
TAM
AÑO
S DE
SSD
PRE
MIU
Tam 4 8 16 32 64 128 256 512 102 2 4 819 16 32

año 4 048 096 2 384 767
de
disc
o
en
GiB
IOP 120 120 120 120 240 500 110 2,30 5.00 750 750 16 18 20.0
S 0 0 0 0 0 000 000 00
por
disc
o
Ren 25 25 25 25 50 100 125 150 200 250 250 500 750 900
o
de
disc
o.
Máx 350 350 350 350 350 350 350 350

imo 0 0 0 0 0 0 0 0
de
IOP
S de
ráfa
ga
por
disc
o**
Ren 170 170 170 170 170 170 170 170

o
máx
imo
de
ráfa
ga
por
disc
o**
TAM
AÑO
S DE
SSD
PRE
MIU
Dur 30 30 30 30 30 30 30 30
n
máx
ima
de
ráfa
ga*
*
**Indica una característica que se encuentra actualmente en versión preliminar; consulte Envío de ráfagas en disco
para más información.
Escenarios de ejemplo
Para obtener una idea más clara de cómo funciona, estos son algunos escenarios de ejemplo:
Un escenario común que se puede beneficiar de la ampliación del disco es el arranque de VM más rápido y
el inicio de aplicaciones en discos del sistema operativo. Tomemos una VM Linux con una imagen del
sistema operativo de 8 GiB como ejemplo. Si usamos un disco P2 como disco del sistema operativo, el
objetivo aprovisionado es de 120 IOPS y 25 MBps. Cuando se inicie la VM, se producirá un pico de lectura
en el disco del sistema operativo que carga los archivos de arranque. Con la introducción de la ampliación,
puede leer la velocidad máxima de ráfaga de 3500 IOPS y 170 MBps, lo que acelera el tiempo de carga 6
veces como mínimo. Después del arranque de la VM, el nivel de tráfico en el disco del sistema operativo
suele ser bajo, ya que la mayoría de las operaciones de datos de la aplicación se realizarán en los discos de
datos conectados. Si el tráfico está por debajo del objetivo aprovisionado, se acumularán créditos.
Si hospeda un entorno de escritorio virtual remoto, siempre que un usuario activo inicie una aplicación
como AutoCAD, el tráfico de lectura en el disco del sistema operativo aumentará significativamente. En este
caso, el tráfico de ráfaga consumirá créditos acumulados, lo que le permitirá ir más allá del objetivo
aprovisionado e iniciar la aplicación mucho más rápido.
Un disco P1 tiene un objetivo aprovisionado de 120 IOPS y 25 MBps. Si el tráfico real del disco era de
100 IOPS y 20 MBps en el último intervalo de 1 segundo, los 20 IOPS y 5 MB no usados se abonan en el
cubo de ráfagas del disco. Los créditos del cubo de ráfagas se pueden usar posteriormente cuando el tráfico
supera el objetivo aprovisionado hasta el límite máximo de ráfagas. El límite máximo de ráfagas define el
límite superior del tráfico del disco, incluso si tiene créditos de ráfagas para consumir. En este caso, aunque
tenga 10 000 IOPS en el cubo de crédito, un disco P1 no puede emitir más de la ráfaga máxima de
3500 IOPS.
Pasos siguientes
Conexión de un disco de datos administrado a una VM de Windows mediante Azure Portal
Objetivos de escalabilidad y rendimiento para discos
de máquinas virtuales con Windows
Puede asociar un número de discos de datos a una máquina virtual de Azure. Según los objetivos de escalabilidad
y rendimiento de los discos de datos de una máquina virtual, puede determinar el número y el tipo de disco
necesarios para satisfacer sus requisitos de capacidad y rendimiento.
IMPORTANT
Para obtener un rendimiento óptimo, limite el número de discos muy usados que se conectan a la máquina virtual para evitar
una posible limitación. Si todos los discos asociados no se usan mucho al mismo tiempo, la máquina virtual puede admitir un
mayor número de discos.
Para discos administrados de Azure:

En la tabla siguiente se muestran los límites predeterminado y máximo del número de recursos por región y
suscripción. No hay ningún límite en el número de discos administrados, instantáneas e imágenes por grupo de
recursos.
RECURSO LÍMITE PREDETERMINADO LÍMITE MÁXIMO
Discos administrados estándar 50.000 50.000
Discos administrados SSD estándar 50.000 50.000
Discos administrados Premium 50.000 50.000
Instantáneas Standard_LRS 50.000 50.000
Instantáneas Standard_ZRS 50.000 50.000
Imagen administrada 50.000 50.000
Para cuentas de almacenamiento estándar: una cuenta de almacenamiento estándar tiene una tasa de
solicitudes máxima total de 20 000 IOPS. El número total de IOPS en todos los discos de máquina virtual
de una cuenta de almacenamiento estándar no debe superar este límite.
Puede calcular aproximadamente el número de discos muy usados que admite una sola cuenta de
almacenamiento estándar en función del límite de tasa de solicitudes. Por ejemplo, en el caso de una
máquina virtual de nivel Básico, el número máximo de discos muy usados está alrededor de 66, que
equivale a 20 000/300 IOPS por disco. El número máximo de discos muy usados para una máquina virtual
de nivel Estándar es de aproximadamente 40, que equivale a 20 000/500 IOPS por disco.
Para cuentas de almacenamiento premium: una cuenta de almacenamiento premium tiene una
capacidad total máxima de proceso de 50 Gbps. La capacidad total de proceso en todos los discos de la
máquina virtual no debe superar este límite.
Consulte Tamaños de las máquinas virtuales Windows en Azure para obtener más detalles.
Discos de máquinas virtuales administrados
Los tamaños marcados con un asterisco están actualmente en versión preliminar. Consulte nuestras preguntas más
frecuentes para obtener información sobre en qué regiones están disponibles.
Discos administrados HDD estándar
TIPO
DE
DISCO
ESTÁN
DAR S4 S6 S10 S15 S20 S30 S40 S50 S60 S70 S80
Tamañ 32 64 128 256 512 1024 2 048 4 096 8192 16 32

o de 384 767
disco
en GiB
IOPS Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta
por 500 500 500 500 500 500 500 500 1300 2000 2000
disco
Rendi Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta
mient 60 60 60 60 60 60 60 60 300 500 500
o de MiB/s MiB/s MiB/s MiB/s MiB/s MiB/s MiB/s MiB/s MiB/s MiB/s MiB/s
disco.
Discos administrados SSD estándar
TAM
AÑO
S DE
SSD
EST
ÁND
Tam 4 8 16 32 64 128 256 512 102 2 4 819 16 32

año 4 048 096 2 384 767
de
disc
o
en
GiB
IOP Has Has Has Has Has Has Has Has Has Has Has Has Has Has
S ta ta ta ta ta ta ta ta ta ta ta ta ta ta
por 120 120 120 120 240 500 500 500 500 500 500 200 400 600
disc 0 0 0
o
Ren Has Has Has Has Has Has Has Has Has Has Has Has Has Has
dimi ta ta ta ta ta ta ta ta ta ta ta ta ta ta
ent 25 25 25 25 50 60 60 60 60 60 60 400 600 750
o MiB MiB MiB MiB MiB MiB MiB MiB MiB MiB MiB Mi Mi MiB
de /s /s /s /s /s /s /s /s /s /s /s B/s B/s /s
disc
o.
Discos administrados SSD Premium: límites por disco
TAM
AÑO
S DE
SSD
PRE
MIU
Tam 4 8 16 32 64 128 256 512 102 2 4 819 16 32

año 4 048 096 2 384 767
de
disc
o
en
GiB
IOP 120 120 120 120 240 500 110 2,30 5.00 750 750 16 18 20.0
S 0 0 0 0 0 000 000 00
por
disc
o
Ren 25 25 25 25 50 100 125 150 200 250 250 500 750 900
o
de
disc
o.
Máx 350 350 350 350 350 350 350 350

imo 0 0 0 0 0 0 0 0
de
IOP
S de
ráfa
ga
por
disc
o**
Ren 170 170 170 170 170 170 170 170

o
máx
imo
de
ráfa
ga
por
disc
o**
TAM
AÑO
S DE
SSD
PRE
MIU
Dur 30 30 30 30 30 30 30 30
n
máx
ima
de
ráfa
ga*
*
disponibilidad regional, consulte Nuevos tamaños de disco: Administrados y no administrados.**Indica una
característica que se encuentra actualmente en versión preliminar; consulte Envío de ráfagas en disco para más
información.
Discos administrados SSD Premium: límites por máquina virtual
RECURSO LÍMITE PREDETERMINADO
Número máximo de IOPS por máquina virtual 80 000 IOPS con máquina virtual GS5
Rendimiento máximo por máquina virtual 2000 MB/s con máquina virtual GS5
Discos de máquinas virtuales no administrados

Discos de máquina virtual administrados estándar: límites por disco
NIVEL DE MÁQUINA VIRTUAL MÁQUINA VIRTUAL DE NIVEL BÁSICO MÁQUINA VIRTUAL DE NIVEL ESTÁNDAR
Tamaño del disco 4095 GB 4095 GB
Número máximo de IOPS de 8 KB por 300 500

disco persistente
Número máximo de discos que realizan 66 40

la cantidad máxima de IOPS
Discos de máquina virtual no administrados premium: límites por cuenta
Capacidad total de disco por cuenta 35 TB
Capacidad total de instantáneas por cuenta 10 TB
Ancho de banda máximo por cuenta (entrada + salida1 ) <=50 Gbps
1Entrada hace referencia a todos los datos de las solicitudes que se envían a una cuenta de almacenamiento. Salida
hace referencia a todos los datos de las respuestas que se reciben desde una cuenta de almacenamiento.
Discos de máquina virtual no administrados premium: límites por disco
TIPO DE DISCO DE
PREMIUM
STORAGE P10 P20 P30 P40 P50
Tamaño del disco 128 GB 512 GB 1024 GiB (1 TB) 2048 GiB (2 TB) 4095 GiB (4 TB)
Número máximo 500 2,300 5.000 7500 7500

de IOPS por disco
Rendimiento 100 MB/s 150 MB/s 200 MB/s 250 MB/s 250 MB/s
máximo por disco
Número máximo 280 70 35 17 8

de discos por
cuenta de
almacenamiento
Discos de máquina virtual no administrados premium: límites por máquina virtual
Número máximo de IOPS por máquina virtual 80 000 IOPS con máquina virtual GS5
Rendimiento máximo por máquina virtual 2000 MB/s con máquina virtual GS5
Otras referencias
Límites, cuotas y restricciones de suscripción y servicios de Microsoft Azure
Copia de seguridad y recuperación ante desastres
para discos IaaS de Azure
En este artículo se explica cómo planear la copia de seguridad y recuperación ante desastres (DR ) de discos y
máquinas virtuales (VM ) IaaS en Azure. En este documento se tratan los discos administrados y los no
administrados.
En primer lugar, hablaremos de las funcionalidades de tolerancia a errores integradas en la plataforma Azure que
permite protegerse contra errores locales. Luego, analizaremos los escenarios de desastre que las funcionalidades
integradas no cubren completamente. También se muestran varios ejemplos de escenarios de carga de trabajo a
los que se pueden aplicar distintas consideraciones sobre copia de seguridad y recuperación ante desastres. Luego
se revisan las soluciones posibles para la recuperación ante desastres de discos IaaS.
Introducción
La plataforma Azure usa diversos métodos de redundancia y tolerancia a errores que contribuyen a proteger a los
clientes de errores de hardware localizados. Es posible que los errores locales incluyan problemas con una
máquina del servidor de Azure Storage en la que se almacena parte de los datos de un disco virtual o errores de
una SSD o HDD presente en el servidor. Estos errores de componentes de hardware aislados pueden producirse
durante las operaciones normales.
La plataforma Azure está diseñada para ser resistente a estos errores. Los desastres de gran envergadura pueden
generar errores o inaccesibilidad de muchos servidores de almacenamiento o incluso de un centro de datos
completo. Si bien las máquinas virtuales y los discos normalmente están protegidos de errores localizados, es
preciso seguir otros pasos para proteger la carga de trabajo de errores catastróficos en toda la región, como un
desastre de gran envergadura, que pueden afectar a la máquina virtual y los discos.
Además de la posibilidad de errores de la plataforma, pueden producirse problemas con los datos o la aplicación
de un cliente. Por ejemplo, es posible que una versión nueva de la aplicación realice inadvertidamente un cambio
en los datos que produzca alguna interrupción. En ese caso, tal vez convenga revertir la aplicación y los datos a
una versión anterior que contenga el último buen estado conocido. Para ello, es necesario haber realizado copias
de seguridad periódicas.
Para la recuperación ante desastres regional, debe realizar una copia de los discos de máquina virtual IaaS en otra
región.
Antes de examinar las opciones de copia de seguridad y recuperación ante desastres, repasemos algunos métodos
disponibles para controlar errores localizados.
Resistencia de IaaS de Azure
Resistencia se refiere a la tolerancia a errores normales que se producen en los componentes de hardware.
Resistencia es la capacidad de recuperarse de los errores y seguir funcionando. No se trata de evitar los errores,
sino de responder a ellos de manera que se evite el tiempo de inactividad o la pérdida de datos. El objetivo de la
resistencia es devolver la aplicación a un estado plenamente operativo después de un error. Las máquinas virtuales
y los discos de Azure están diseñados para ser resistentes a errores de hardware comunes. Echemos un vistazo a
cómo la plataforma Azure IaaS proporciona esta resistencia.
Una máquina virtual se compone principalmente de dos partes: un servidor de proceso y los discos persistentes.
Ambos componentes afectan a la tolerancia a errores de una máquina virtual.
Si el servidor host de proceso de Azure que hospeda la máquina virtual experimenta un error de hardware, lo que
es poco frecuente, Azure está diseñado para restaurar automáticamente la máquina virtual en otro servidor. Si
esto sucede, el equipo se reinicia y la máquina virtual vuelve a activarse después de un tiempo. Azure detecta
automáticamente estos errores de hardware y ejecuta las recuperaciones para ayudar a garantizar que la máquina
virtual del cliente esté disponible cuanto antes.
Con respecto a los discos IaaS, la durabilidad de los datos es fundamental en una plataforma de almacenamiento
persistente. Los clientes de Azure tienen aplicaciones empresariales importantes que se ejecutan en IaaS y
dependen de la persistencia de los datos. Azure diseña la protección de estos discos IaaS con tres copias
redundantes de datos almacenados localmente. Estas copian ofrecen gran durabilidad contra errores locales. Si se
produce un error en uno de los componentes de hardware que contiene el disco, la máquina virtual no se ve
afectada porque hay dos copias adicionales que admiten las solicitudes de disco. Funciona bien, aunque dos
componentes de hardware distintos que admiten un disco tengan errores al mismo tiempo (lo que es muy poco
frecuente).
Para asegurar que siempre se mantienen tres réplicas, Azure Storage genera automáticamente una nueva copia de
datos en segundo plano si una de las tres copias deja de estar disponible. Por consiguiente, no debe ser necesario
utilizar usar RAID con discos de Azure para tolerancia a errores. Una configuración simple de RAID 0 debe ser
suficiente para seccionar los discos si es necesario para crear volúmenes más grandes.
Gracias a esta arquitectura, Azure ha ofrecido de manera constante durabilidad de nivel empresarial para discos
IaaS, con una tasa de error anualizada de cero por cierto líder en el sector.
Los errores de hardware localizados en el host de proceso o en la plataforma de almacenamiento pueden en
ocasiones traducirse en falta de disponibilidad temporal de la máquina virtual que está cubierta por el contrato de
nivel de servicio de Azure para disponibilidad de la máquina virtual. Azure ofrece también un Acuerdo de Nivel de
Servicio (SLA) líder del sector para instancias únicas de máquina virtual que usan discos SSD premium de Azure.
Para proteger las cargas de trabajo de aplicación de tiempo de inactividad debido a la falta temporal de
disponibilidad de un disco o una máquina virtual, los clientes pueden usar los conjuntos de disponibilidad. Dos
máquinas virtuales o más de un conjunto de disponibilidad proporcionan redundancia para la aplicación. Azure
luego crea estas máquinas virtuales y discos en dominios de error independientes con distintos componentes de
alimentación, red y servidor.
Debido a estos dominios de error independientes, los errores de hardware localizados normalmente no afectan a
varias máquinas virtuales del conjunto al mismo tiempo. Tener dominios de error independientes proporciona alta
disponibilidad de la aplicación. Se recomienda usar conjuntos de disponibilidad cuando se requiere alta
disponibilidad. La sección siguiente abarca el aspecto de la recuperación ante desastres.
Copia de seguridad y recuperación ante desastres
La recuperación ante desastres es la capacidad de recuperarse de incidentes poco frecuentes, pero de gran
envergadura. Esto incluye errores no transitorios de gran escala, como una interrupción del servicio que afecta a
toda una región. La recuperación ante desastres incluye la copia de seguridad y el archivado de datos, y puede
incluir la intervención manual, como la restauración manual de una base de datos a partir de una copia de
seguridad.
Puede que la protección integrada frente a errores localizados de la plataforma de Azure no proteja
completamente la máquina virtual y los discos si un desastre de gran envergadura provoca interrupciones a gran
escala. Estas incluyen eventos catastróficos tales como que un centro de datos se vea afectado por un huracán,
terremoto, incendio o si hay errores de unidades de hardware a gran escala. Además, se pueden producir errores
debido a problemas de datos o aplicaciones.
Para contribuir a proteger de interrupciones las cargas de trabajo de IaaS, debe planear redundancia y tener copias
de seguridad para habilitar la recuperación. Para la recuperación ante desastres, debe crear una copia de seguridad
en una ubicación geográfica distinta fuera del sitio principal. Así se ayuda a garantizar que la copia de seguridad
no se ve afectada por el mismo evento que originalmente afectó la máquina virtual o los discos. Para más
información, consulte Recuperación ante desastres para aplicaciones de Azure.
Las consideraciones sobre recuperación ante desastres pueden incluir los aspectos siguientes:
Alta disponibilidad: la capacidad de la aplicación de seguir ejecutándose en un estado correcto, sin tiempo
de inactividad relevante. Por estado correcto, queremos decir que la aplicación responde y los usuarios
pueden conectarse e interactuar con ella. Ciertas bases de datos y aplicaciones críticas pueden tener que
estar disponibles siempre, aunque existan errores en la plataforma. Para estas cargas de trabajo, puede que
necesite planear la redundancia para la aplicación, así como para los datos.
Durabilidad de los datos: en ciertos casos, la consideración más importante es garantizar que los datos se
conserven si se produce un desastre. Por consiguiente, puede que tenga que realizar una copia de
seguridad de los datos en otro sitio. Para estas cargas de trabajo, es posible que no se requiera una
redundancia completa para la aplicación, sino solo una copia de seguridad periódica de los discos.
Escenarios de copia de seguridad y recuperación ante desastres

Veamos algunos ejemplos típicos de escenarios de carga de trabajo de aplicación y las consideraciones sobre la
planeación de recuperación ante desastres.
Escenario 1: Soluciones de bases de datos principales
Considere la posibilidad de usar un servidor de base de datos de producción, como SQL Server u Oracle, que
pueda admitir alta disponibilidad. Los usuarios y las aplicaciones de producción críticas dependen de esta base de
datos. Es posible que el plan de recuperación ante desastres para este sistema tenga que admitir los requisitos
siguientes:
Los datos deben estar protegidos y ser recuperables.
El servidor debe estar disponible para su uso.
El plan de recuperación ante desastres puede requerir que se mantenga una réplica de la base de datos en una
región distinta como copia de seguridad. Según los requisitos para la recuperación de datos y la disponibilidad del
servidor, la solución podría variar de un sitio de réplica activa-pasiva o activa-activa para copias de seguridad
periódicas sin conexión de los datos. Las bases de datos relacionales, como SQL Server y Oracle, ofrecen varias
opciones de replicación. Con SQL Server, use los Grupos de disponibilidad AlwaysOn de SQL Server para alta
disponibilidad.
Las bases de datos NoSQL, como MongoDB, también admiten réplicas para conseguir redundancia. Se usan las
réplicas de caché para conseguir alta disponibilidad.
Escenario 2: Un clúster de máquinas virtuales redundantes
Considere la posibilidad de una carga de trabajo controlada por un clúster de máquinas virtuales que
proporcionan redundancia y equilibrio de carga. Un ejemplo es un clúster Cassandra implementado en una región.
Este tipo de arquitectura ya proporciona un alto nivel de redundancia en esa región. Pero, para proteger la carga
de trabajo de un error de nivel regional, debe plantearse la posibilidad de propagar el clúster en dos regiones o
realizar copias de seguridad periódicas en otra región.
Escenario 3: Carga de trabajo de la aplicación IaaS
Analicemos la carga de trabajo de la aplicación IaaS. Por ejemplo, podría tratarse de una carga de trabajo de
producción típica que se ejecuta en una máquina virtual de Azure. Podría ser un servidor web o servidor de
archivos que contiene el contenido y otros recursos de un sitio. También podría ser una aplicación empresarial
personalizada que se ejecuta en una máquina virtual que almacena los datos, los recursos y el estado de la
aplicación en los discos de máquina virtual. En este caso, es importante asegurarse de realizar copias de seguridad
periódicamente. La frecuencia de copia de seguridad debe basarse en la naturaleza de la carga de trabajo de
máquina virtual. Por ejemplo, si la aplicación se ejecuta todos los días y modifica los datos, la copia de seguridad
debe realizarse cada hora.
Otro ejemplo es un servidor de informes que extrae datos de otros orígenes y genera informes agregados. La
pérdida de esta máquina virtual o estos discos se podría traducir en la pérdida de los informes. Pero, tal vez sea
posible volver a ejecutar el proceso de creación de informes y volver a generar la salida. En ese caso, en realidad
no se tiene una pérdida de datos, incluso si un desastre azota el servidor de informes. Como resultado, podría
tener un nivel mayor de tolerancia a perder parte de los datos en el servidor de informes. En ese caso, realizar
copias de seguridad con menor frecuencia es una posibilidad para reducir los costos.
Escenario 4: Problemas de datos de la aplicación IaaS
Los problemas de datos de la aplicación IaaS son otra posibilidad. Considere una aplicación que calcula, mantiene
y sirve de datos comerciales críticos, como información sobre los precios. Una nueva versión de la aplicación tenía
un error de software que calculó incorrectamente el precio y dañó los datos comerciales existentes servidos por la
plataforma. En este caso, la mejor medida es revertir a la versión anterior de la aplicación y los datos. Para
habilitarla, realice copias de seguridad periódicas del sistema.
Solución de recuperación ante desastres: Azure Backup

Azure Backup se usa para copias de seguridad y recuperaciones ante desastres y funciona tanto con discos
administrados como con discos no administrados. Puede crear un trabajo de copia de seguridad con copias de
seguridad basadas en tiempo, fácil restauración de la máquina virtual y directivas de retención de copia de
seguridad.
Si usa discos SSD premium, discos administrados o discos de otros tipos con la opción de almacenamiento con
redundancia local, es especialmente importante crear copias de seguridad periódicas de recuperación ante
desastres. Azure Backup almacena los datos en el almacén de Recovery Services para su retención a largo plazo.
Elija la opción de almacenamiento con redundancia geográfica opción para el almacén de Backup Recovery
Services. Esa opción garantiza que las copias de seguridad se repliquen en una región distinta de Azure para su
protección contra desastres regionales.
Con discos no administrados, puede usar el tipo de almacenamiento con redundancia local para discos IaaS, pero
asegúrese de que Azure Backup esté habilitado con la opción de almacenamiento con redundancia geográfica en
el almacén de Recovery Services.
NOTE
Si usa la opción almacenamiento con redundancia geográfica o almacenamiento con redundancia geográfica con acceso de
lectura con los discos no administrados, todavía necesita instantáneas coherentes de copia de seguridad y recuperación ante
desastres. Use Azure Backup o instantáneas coherentes.
En la tabla siguiente se muestra un resumen de las soluciones disponibles para la recuperación ante desastres.
SOLUCIÓN DE RECUPERACIÓN ANTE

ESCENARIO REPLICACIÓN AUTOMÁTICA DESASTRES
Discos SSD premium Local (almacenamiento con redundancia Azure Backup

local)
Discos administrados Local (almacenamiento con redundancia Azure Backup

local)
Discos no administrados de Local (almacenamiento con redundancia Azure Backup

almacenamiento con redundancia local local)
SOLUCIÓN DE RECUPERACIÓN ANTE
ESCENARIO REPLICACIÓN AUTOMÁTICA DESASTRES
Discos no administrados de Entre regiones (almacenamiento con Azure Backup

almacenamiento con redundancia redundancia geográfica) Instantáneas coherentes
geográfica
Discos no administrados de Entre regiones (almacenamiento con Azure Backup

almacenamiento con redundancia redundancia geográfica con acceso de Instantáneas coherentes
geográfica con acceso de lectura lectura)
La alta disponibilidad puede conseguirse mejor mediante los discos administrados en un conjunto de
disponibilidad con Azure Backup. Si usa discos no administrados, de todos modos puede usar Azure Backup para
recuperación ante desastres. Si no puede usar Azure Backup, tome instantáneas coherentes tal y como se describe
en una sección posterior es una solución alternativa de copia de seguridad y recuperación ante desastres.
Las opciones de alta disponibilidad, copia de seguridad y recuperación ante desastres en los niveles de aplicación o
de infraestructura se pueden representar como sigue:
COPIA DE SEGURIDAD O RECUPERACIÓN

NIVEL ALTA DISPONIBILIDAD ANTE DESASTRES
Application SQL Server AlwaysOn Azure Backup
Infraestructura Conjunto de disponibilidad Almacenamiento con redundancia

geográfica con instantáneas coherentes
Uso de Azure Backup

Azure Backup puede realizar copias de seguridad de las máquinas virtuales que ejecutan Windows o Linux en el
almacén de Azure Recovery Services. La copia de seguridad y restauración de datos críticos para el negocio resulta
complicada por el hecho de que hay que realizar la copia de seguridad mientras se ejecutan las aplicaciones que
producen los datos.
Para solucionar el problema, Azure Backup ofrece copias de seguridad coherentes con la aplicación para las cargas
de trabajo de Microsoft. Usa el servicio de instantáneas de volumen para garantizar que los datos se escriben
correctamente en el almacenamiento. En las máquinas virtuales Linux, el modo de coherencia predeterminado de
las copias de seguridad son las copias de seguridad coherentes con el archivo, dado que Linux no dispone de una
funcionalidad equivalente al servicio de instantáneas de volumen como en el caso de Windows. Para máquinas de
Linux, consulte Copias de seguridad coherentes con la aplicación de las máquinas virtuales Linux de Azure.
El servicio Azure Backup inicia el trabajo de copia de seguridad a la hora programada y desencadena la extensión
de reserva instalada en la máquina virtual para tomar una instantánea de un momento dado. Esta instantánea se
toma en coordinación con el servicio de instantáneas de volumen para obtener una instantánea coherente de los
discos de la máquina virtual sin tener que apagarla. La extensión de reserva de la máquina virtual realiza un
vaciado de todas las escrituras antes de tomar una instantánea coherente de todos los discos. Después de tomar la
instantánea, el servicio Azure Backup transfiere los datos al almacén de Backup. Para que el proceso de copia de
seguridad resulte más eficaz, el servicio identifica y transfiere únicamente los bloques de datos que han cambiado
desde la última copia de seguridad.
Para restaurarlos, puede ver las copias de seguridad disponibles a través de Azure Backup y luego iniciar una
restauración. Puede crear y restaurar copias de seguridad de Azure a través de Azure Portal, mediante PowerShell
o mediante la CLI de Azure.
Pasos para habilitar una copia de seguridad
Use los pasos siguientes para habilitar las copias de seguridad de las máquinas virtuales mediante Azure Portal.
Hay algunas variaciones según el escenario exacto. Consulte la documentación de Azure Backup para obtener
todos los detalles. Azure Backup también admite máquinas virtuales con discos administrados.
1. Creación de un almacén de servicios de recuperación para una máquina virtual:
a. En Azure Portal, examine Todos los recursos y busque Almacenes de Recovery Services.
b. En el menú Almacenes de Recovery Services, haga clic en Agregar y siga estos pasos para crear otro
almacén en la misma región que la máquina virtual. Por ejemplo, si la máquina virtual se encuentra en la
región del oeste de EE. UU, elija Oeste de EE. UU. para el almacén.
2. Compruebe la replicación de almacenamiento para el almacén recién creado. Acceda al almacén en
Almacenes de Recovery Services y vaya a Propiedades > Configuración de copia de seguridad >
Actualizar. Asegúrese de que la opción de almacenamiento con redundancia geográfica está
seleccionada de manera predeterminada. Así se asegura de que el almacén se replique automáticamente en
un centro de datos secundario. Por ejemplo, el almacén de la región oeste de EE. UU. se replica
automáticamente en la región este de EE. UU.
3. Configure la directiva de copia de seguridad y seleccione la máquina virtual en la misma interfaz de usuario.
4. Asegúrese de que Backup Agent está instalado en la máquina virtual. Si la máquina virtual se crea con una
imagen de la galería de Azure, ya tiene instalado el agente de copia de seguridad. En caso contrario (es
decir, si usa una imagen personalizada), siga las instrucciones para instalar el agente de VM en una máquina
virtual.
5. Asegúrese de que la máquina virtual permite la conectividad de red para que funcione el servicio Backup.
Siga las instrucciones para la conectividad de red.
6. Una vez completados los pasos anteriores, la copia de seguridad se ejecuta a intervalos regulares, tal y
como se especifica en la directiva de copia de seguridad. Si es necesario, puede desencadenar la primera
copia de seguridad manualmente desde el panel de almacén en Azure Portal.
Para la automatización de Azure Backup mediante scripts, consulte Cmdlets de PowerShell para copia de
seguridad de máquina virtual.
Pasos para la recuperación
Si tiene que reparar o volver a generar una máquina virtual, puede restaurarla desde cualquiera de los puntos de
recuperación de copia de seguridad del almacén. Hay un par de opciones diferentes para realizar la recuperación:
Puede crear otra máquina virtual como una representación de un momento dado de la máquina virtual de
copia de seguridad.
Puede restaurar los discos y luego usar la plantilla de la máquina virtual para personalizar y volver a
generar la máquina virtual restaurada.
Para más información, consulte las instrucciones para usar Azure Portal para restaurar máquinas virtuales. En este
documento se explican también los pasos concretos para restaurar máquinas virtuales con copia de seguridad en
un centro de datos emparejado mediante el almacén de Backup con redundancia geográfica si se produce algún
desastre en el centro de datos principal. En ese caso, Azure Backup usa el servicio Compute de la segunda región
para crear la máquina virtual restaurada.
También puede usar PowerShell para crear una máquina virtual a partir de discos restaurados.
Soluciones alternativas: Instantáneas coherentes

Si no puede usar Azure Backup, puede implementar su propio mecanismo de copia de seguridad con instantáneas.
Resulta complicado crear las instantáneas coherentes para todos los discos usados que usa una máquina virtual y
luego replicar esas instantáneas en otra región. Por esta razón, Azure considera mejor opción usar el servicio
Backup que compilar una solución personalizada.
Si usa el almacenamiento con redundancia geográfica con acceso de lectura o el almacenamiento con redundancia
geográfica para los discos, las instantáneas se replican automáticamente en un centro de datos secundario. Si se
usa el almacenamiento con redundancia local para los discos, el usuario debe replicar los datos por sí mismo. Para
más información, consulte Copias de seguridad de discos de máquinas virtuales de Azure no administrados con
instantáneas incrementales.
Una instantánea es una representación de un objeto en un momento dado. Una instantánea se factura según el
tamaño incremental de los datos que contiene. Para más información, vea Creación de una instantánea de un blob.
Creación de instantáneas mientras la máquina virtual está en ejecución
Aunque puede tomar una instantánea en cualquier momento, si la máquina virtual se está ejecutando, todavía hay
datos que se transmiten a los discos. Las instantáneas pueden contener operaciones parciales que estaban en
marcha. Además, si intervienen varios discos, es posible que se hayan producido instantáneas de distintos discos
en distintos momentos. Estos escenarios pueden provocar que las instantáneas se descoordinen. Esta falta de
coordinación es especialmente problemática para los volúmenes seccionados cuyos archivos pueden resultar
dañados si se realizan cambios durante la copia de seguridad.
Para evitar esta situación, el proceso de copia de seguridad debe implementar los siguientes pasos:
1. Inmovilice todos los discos.
2. Vacíe todas las escrituras pendientes.
3. Cree una instantánea de un blob para todos los discos.
Algunas aplicaciones de Windows como SQL Server ofrecen un mecanismo de copia de seguridad coordinado a
través de un servicio de instantáneas de volumen para crear copias de seguridad coherentes con la aplicación. En
Linux, puede usar una herramienta como fsfreeze para coordinar los discos. Esta herramienta brinda copias de
seguridad coherentes con el archivo, pero no instantáneas coherentes con la aplicación. Este proceso es complejo,
por lo que debe plantarse el uso de Azure Backup o una solución de copia de seguridad de terceros que ya lo
implementen.
El proceso anterior da como resultado una colección de instantáneas coordinadas de todos los discos de máquina
virtual, que representa una vista de un momento dado de la máquina virtual. Se trata de un punto de restauración
de copia de seguridad para la máquina virtual. Puede repetir el proceso a intervalos programados para crear
copias de seguridad periódicas. En Copia de las instantáneas en otra región, consulte los pasos para copiar las
instantáneas en otra región para la recuperación ante desastres.
Creación de instantáneas mientras la máquina virtual está sin conexión
Otra posibilidad para crear copias de seguridad coherentes es apagar la máquina virtual y tomar instantáneas de
blob de cada disco. Tomar instantáneas de blob resulta más sencillo que coordinar instantáneas de una máquina
virtual en ejecución, pero requiere algunos minutos de inactividad.
1. Apague la máquina virtual.
2. Cree una instantánea de cada blob de disco duro virtual, que solo tarda unos segundos.
Para crear una instantánea, puede usar PowerShell, la API de REST de Azure Storage, la CLI de Azure o
cualquiera de las bibliotecas de cliente de Azure Storage, como la biblioteca del cliente de Storage para
.NET.
3. Inicie la máquina virtual, con lo que finaliza el tiempo de inactividad. Todo el proceso se completa
habitualmente en unos minutos.
Este proceso produce una colección de instantáneas coherentes de todos los discos, lo que proporciona un punto
de restauración de copia de seguridad para la máquina virtual.
Copia de las instantáneas en otra región
La creación de las instantáneas por sí sola puede no ser suficiente para la recuperación ante desastres. También
debe replicar las copias de seguridad de instantánea en otra región.
Si usa el almacenamiento con redundancia geográfica o el almacenamiento con redundancia geográfica con
acceso de lectura para los discos, las instantáneas se replican automáticamente en la región secundaria. Puede
haber unos minutos de retraso antes de la replicación. Si el centro de datos principal deja de funcionar antes de
que se complete la replicación de las instantáneas, no puede acceder a las instantáneas desde el centro de datos
secundario. La probabilidad de que esto ocurra es pequeña.
NOTE
Tener los discos solo en una cuenta de almacenamiento con redundancia geográfica con acceso de lectura o almacenamiento
con redundancia geográfica no protege de desastres la máquina virtual. También debe crear instantáneas coordinadas o usar
Azure Backup. Esto es necesario para recuperar una máquina virtual a un estado coherente.
Si usa el almacenamiento con redundancia local, debe copiar las instantáneas en otra cuenta de almacenamiento
inmediatamente después de crear la instantánea. El destino de copia puede ser una cuenta de almacenamiento con
redundancia local en una región distinta, con lo que la copia se encuentra en una región remota. También puede
copiar la instantánea en una cuenta de almacenamiento con redundancia geográfica con acceso de lectura en la
misma región. En este caso, la instantánea se replica de forma diferida en la región secundaria remota. La copia de
seguridad se protege ante desastres en el sitio principal después de completar la copia de seguridad y la
replicación.
Para copiar las instantáneas incrementales para recuperación ante desastres con eficacia, consulte las instrucciones
dadas en Copias de seguridad de discos de máquinas virtuales de Azure no administrados con instantáneas
incrementales.
Recuperación de instantáneas
Para recuperar una instantánea, cópiela para crear un blob. Si va a copiar la instantánea de la cuenta principal,
puede copiarla en el blob base de la instantánea. Este proceso revierte el disco a la instantánea y se conoce como
promocionar la instantánea. Si va a copiar la copia de seguridad de instantánea de una cuenta secundaria, en el
caso de una cuenta de almacenamiento con redundancia geográfica con acceso de lectura, debe copiarse a una
cuenta principal. Puede copiar una instantánea mediante PowerShell o con la utilidad AzCopy. Para más
información, consulte Transferencia de datos con la utilidad en línea de comandos AzCopy.
En el caso de las máquinas virtuales con varios discos, debe copiar todas las instantáneas que forman parte del
mismo punto de restauración coordinada. Después de copiar las instantáneas en blobs de VHD grabable, puede
usarlos para volver a crear la máquina virtual con la plantilla de la máquina virtual.
Otras opciones
SQL Server
SQL Server en una máquina virtual tiene su propia funcionalidad integrada para realizar copias de seguridad de la
base de datos de SQL Server en Azure Blob Storage o en un recurso compartido de archivos. Si la cuenta de
almacenamiento es almacenamiento con redundancia geográfica o almacenamiento con redundancia geográfica
con acceso de lectura, puede acceder a las copias de seguridad en el centro de datos secundaria de la cuenta de
almacenamiento en caso de desastre, con las mismas restricciones descritas anteriormente. Para más información,
consulte Copias de seguridad y restauración para SQL Server en máquinas virtuales de Azure. Además de la copia
de seguridad y restauración, los grupos de disponibilidad AlwaysOn de SQL Server pueden conservar réplicas
secundarias de las bases de datos. Esta posibilidad reduce considerablemente el tiempo de recuperación ante
desastres.
Otras consideraciones
En este artículo se describe cómo realizar una copia de seguridad o tomar instantáneas de las máquinas virtuales y
sus discos para admitir la recuperación ante desastres y cómo usarlas para recuperar los datos. Con el modelo de
Azure Resource Manager, muchas personas usan plantillas para crear sus máquinas virtuales y otras
infraestructuras en Azure. Puede usar una plantilla para crear una máquina virtual que tenga siempre la misma
configuración. Si usa imágenes personalizadas para crear las máquinas virtuales, debe asegurarse también de que
las imágenes están protegidas con una cuenta de almacenamiento con redundancia geográfica con acceso de
lectura para almacenarlas.
Por lo tanto, el proceso de copia de seguridad puede ser una combinación de estas dos acciones:
Haga una copia de seguridad de los datos (discos).
Haga una copia de seguridad de la configuración (plantillas e imágenes personalizadas).
Según la opción de copia de seguridad que elija, puede que tenga que controlar la copia de seguridad de los datos
y la configuración o hacer que servicio Backup controle todo esto automáticamente.
Apéndice: comprensión del impacto de la redundancia de datos

En el caso de las cuentas de almacenamiento de Azure, hay tres tipos de redundancia de datos que se debe
considerar con respecto a la recuperación ante desastres: con redundancia local, con redundancia geográfica o con
redundancia geográfica con acceso de lectura.
El almacenamiento con redundancia local mantiene tres copias de los datos en el mismo centro de datos. Cuando
la máquina virtual escribe los datos, las tres copias se actualizan antes devolver al autor de la llamada el mensaje
de operación correcta, para que se sepa que son idénticas. El disco está protegido contra errores locales, ya que es
poco probable que las tres copias se vean afectadas al mismo tiempo. En el caso del almacenamiento con
redundancia local, no hay ninguna redundancia geográfica, por lo que el disco no está protegido contra errores
catastróficos que pueden afectar a una unidad de almacenamiento o centro de datos completo.
Con almacenamiento con redundancia geográfica y almacenamiento con redundancia geográfica con acceso de
lectura, se mantienen tres copias de los datos en la región primaria que seleccione. Otras tres copias de los datos
se mantienen en una región secundaria correspondiente establecida por Azure. Por ejemplo, si almacena datos en
la región oeste de EE. UU., los datos se replicarán en la región este de EE. UU. La retención de las copias se hace
forma asincrónica y hay un pequeño retraso entre las actualizaciones en los sitios principal y secundario. Las
réplicas de los discos en el sitio secundario son coherentes por disco (con el retraso), pero puede que las réplicas
de varios discos activos no estén sincronizadas entre sí. Para tener réplicas coherentes en varios discos, se
requieren instantáneas coherentes.
La diferencia principal entre el almacenamiento con redundancia geográfica y el almacenamiento con redundancia
geográfica con acceso de lectura es que con este último puede leer la copia secundaria en cualquier momento. Si
hay un problema que presenta los datos en la región principal inaccesible, el equipo de Azure hace todo lo posible
para restaurar el acceso. Aunque el centro de datos principal esté inactivo, si tiene habilitado el almacenamiento
con redundancia geográfica con acceso de lectura, puede acceder a los datos del centro de datos secundario. Por lo
tanto, si tiene previsto leer desde la réplica cuando el centro de datos principal esté inaccesible, debe plantearse el
uso del almacenamiento con redundancia geográfica con acceso de lectura.
Si resulta ser una interrupción importante, el equipo de Azure puede desencadenar una conmutación por error
geográfica y cambiar las entradas DNS principales para que señalen a un almacenamiento secundario. En este
momento, si tiene habilitado el almacenamiento con redundancia geográfica o el almacenamiento con
redundancia geográfica con acceso de lectura, puede acceder a los datos de la región que se usa como secundaria.
En otras palabras, si la cuenta de almacenamiento es almacenamiento con redundancia geográfica y hay un
problema, solo puede acceder el almacenamiento secundario si existe una conmutación por error geográfica.
Para más información, vea Qué hacer si se produce una interrupción del servicio Azure Storage.
NOTE
Microsoft controla si se produce una conmutación por error. La conmutación por error no se controla por cuenta de
almacenamiento, por lo que no son los clientes individuales quienes deciden su uso. Para implementar la recuperación ante
desastres con cuentas de almacenamiento o discos de máquina virtual en concreto, debe usar las técnicas descritas
anteriormente en este artículo.
Discos de SO efímeros para máquinas virtuales de
Azure
Los discos del sistema operativo efímeros se crean en el almacenamiento local de la máquina virtual y no se
guardan en la instancia remota de Azure Storage. Estos discos están indicados para cargas de trabajo sin estado,
donde las aplicaciones toleran errores de máquinas virtuales individuales, pero tienen más en cuenta el tiempo de
implementación de las máquinas virtuales o el restablecimiento de la imagen inicial de dichas máquinas. Con los
discos del sistema operativo efímeros, observará una latencia de lectura y escritura inferior en el disco del sistema
operativo y un restablecimiento más rápido de la imagen inicial de la máquina virtual.
Las principales características de los discos efímeros son:
Perfecto para las aplicaciones sin estado.
Se pueden usar con imágenes de Marketplace y personalizadas.
Posibilidad de restablecimiento rápido o de restablecimiento de la imagen inicial de las máquinas virtuales y de
las instancias de conjunto de escalado al estado de arranque original.
Latencia inferior, similar a la de un disco temporal.
Los discos del sistema operativo efímeros son gratuitos, es decir, no generan costos de almacenamiento.
Están disponibles en todas las regiones de Azure.
El disco de sistema operativo efímero es compatible con Shared Image Gallery.
Principales diferencias entre discos del sistema operativo efímeros y persistentes:
DISCO DEL SISTEMA DISCO DE SISTEMA OPERATIVO

OPERATIVO PERSISTENTE EFÍMERO
Límite de tamaño del disco 2 TiB El tamaño de caché para el

del sistema operativo tamaño de máquina virtual o
2 TiB, el que sea menor. Para
el tamaño de caché en GiB,
consulte DS, ES, M, FS y GS.
Tamaños de máquina virtual Todo DSv1, DSv2, DSv3, Esv3, Fs,

admitidos FsV2, GS, M
Compatibilidad con los tipos Disco del sistema operativo Solo disco del sistema
de discos administrado y no operativo administrado
administrado
Regiones admitidas Todas las regiones Todas las regiones
Persistencia de los datos Los datos del disco del Los datos escritos en un
sistema operativo escritos en disco del sistema operativo
un disco del sistema se almacenan en el
operativo se almacenan en almacenamiento de máquina
Azure Storage. virtual local y no se
conservan en Azure Storage.
DISCO DEL SISTEMA DISCO DE SISTEMA OPERATIVO
OPERATIVO PERSISTENTE EFÍMERO
Estado detenido Las máquinas virtuales y las Las máquinas virtuales y las
(desasignado) instancias del conjunto de instancias del conjunto de
escalado pueden estar escalado no pueden estar
detenidas (desasignadas) y detenidas (desasignadas).
reiniciarse a partir de este
estado.
Compatibilidad con discos Sí Sin

del sistema operativo
especializados
Cambio de tamaño del disco Se admite durante la Se admite solo durante la

del sistema operativo creación de la máquina creación de la máquina
virtual y después de que virtual
esta se detiene (desasigna).
Cambio a un nuevo tamaño Se conservan los datos del Se eliminan los datos del
de máquina virtual disco del sistema operativo disco del sistema operativo,
se vuelve a aprovisionar el
sistema operativo.
Requisitos de tamaño
Puede implementar imágenes de instancias y de máquinas virtuales hasta el tamaño de la caché de máquina
virtual. Por ejemplo, las imágenes estándar de Windows Server de Marketplace son de aproximadamente 127 GiB,
lo que significa que necesita un tamaño de máquina virtual que tenga una caché de más de 127 GiB. En este caso,
las máquinas virtuales Standard_DS2_v2 tienen un tamaño de caché de 86 GiB, que no es lo suficientemente
grande. Las máquinas virtuales Standard_DS3_v2 tienen un tamaño de caché de 172 GiB, que es lo
suficientemente grande. En este caso, Standard_DS3_v2 tienen el tamaño menor de la serie DSv2 que se puede
usar con esta imagen. Las imágenes básicas de Linux en Marketplace y las imágenes de Windows Server indicadas
por [smallsize] tienden a tener alrededor de 30 GiB y pueden usar la mayoría de los tamaños de máquinas
virtuales disponibles.
Los discos efímeros también requieren que el tamaño de la máquina virtual admita Premium Storage. Los
tamaños normalmente (pero no siempre) tienen un s en el nombre, como DSv2 y EsV3. Para más información,
consulte Tamaños de máquinas virtuales de Azure para más información sobre qué tamaños se admiten Premium
Storage.
PowerShell
Para usar un disco efímero para una implementación de máquina virtual de PowerShell, utilice Set-AzVMOSDisk
en la configuración de la máquina virtual. Establezca -DiffDiskSetting en Local y -Caching en ReadOnly .
Set-AzVMOSDisk -DiffDiskSetting Local -Caching ReadOnly
Para las implementaciones de conjunto de escalado, use el cmdlet Set-AzVmssStorageProfile en la configuración.

Establezca -DiffDiskSetting en Local y -Caching en ReadOnly .
Set-AzVmssStorageProfile -DiffDiskSetting Local -OsDiskCaching ReadOnly

CLI
Para usar un disco efímero para una implementación de la máquina virtual de la CLI, establezca el parámetro
--ephemeral-os-disk de az vm create en true y el parámetro --os-disk-caching en ReadOnly .
az vm create \
--name myVM \
--image UbuntuLTS \
--ephemeral-os-disk true \
--os-disk-caching ReadOnly \
--generate-ssh-keys
Para los conjuntos de escalado, use el mismo parámetro --ephemeral-os-disk true para az vmss create y
establezca el parámetro --os-disk-caching en ReadOnly .
Portal
En Azure Portal, puede elegir usar discos efímeros al implementar una máquina virtual, abra la sección Advanced
(Avanzadas) de la pestaña Disks (Discos). Para Use ephemeral OS disk (Utilizar disco de sistema operativo
efímero) seleccione Yes (Sí).
Si la opción de utilizar un disco efímero está atenuada, es posible que haya seleccionado un tamaño de máquina
virtual que no tenga un tamaño de caché mayor que la imagen del sistema operativo o que no admita Premium
Storage. Vuelva a la página Basics (Aspectos básicos) y pruebe con otro tamaño de máquina virtual.
También puede crear conjuntos de escalado con discos de sistema operativo efímeros mediante el portal.
Asegúrese de seleccionar un tamaño de máquina virtual que tenga un tamaño de caché lo suficientemente grande
y, a continuación, en Use ephemeral OS disk (Utilizar disco de sistema operativo efímero) seleccione Yes (Sí).
Implementación de plantillas de conjunto de escalado
El proceso para crear un conjunto de escalado que use un disco del sistema operativo efímero consiste en agregar
la propiedad diffDiskSettings al tipo de recurso Microsoft.Compute/virtualMachineScaleSets/virtualMachineProfile
en la plantilla. Además, la directiva de almacenamiento en caché debe establecerse en ReadOnly para el disco del
sistema operativo efímero.
{
"type": "Microsoft.Compute/virtualMachineScaleSets",
"name": "myScaleSet",
"location": "East US 2",
"apiVersion": "2018-06-01",
"sku": {
"name": "Standard_DS2_v2",
"capacity": "2"
},
"properties": {
"upgradePolicy": {
"mode": "Automatic"
},
"virtualMachineProfile": {
"storageProfile": {
"osDisk": {
"diffDiskSettings": {
"option": "Local"
},
"caching": "ReadOnly",
"createOption": "FromImage"
},
"imageReference": {
"publisher": "Canonical",
"offer": "UbuntuServer",
"sku": "16.04-LTS",
"version": "latest"
}
},
"osProfile": {
"computerNamePrefix": "myvmss",
"adminUsername": "azureuser",
"adminPassword": "P@ssw0rd!"
}
}
}
}
Implementación de plantillas de máquinas virtuales

Puede implementar una máquina virtual con un disco del sistema operativo efímero mediante una plantilla. El
proceso para crear una máquina virtual que use discos del sistema operativo efímeros consiste en agregar la
propiedad diffDiskSettings al tipo de recurso Microsoft.COMPUTE/virtualmachines en la plantilla. Además, la
directiva de almacenamiento en caché debe establecerse en ReadOnly para el disco del sistema operativo efímero.
{
"type": "Microsoft.Compute/virtualMachines",
"name": "myVirtualMachine",
"location": "East US 2",
"apiVersion": "2018-06-01",
"properties": {
"storageProfile": {
"osDisk": {
"diffDiskSettings": {
"option": "Local"
},
"caching": "ReadOnly",
},
"imageReference": {
"publisher": "MicrosoftWindowsServer",
"offer": "WindowsServer",
"sku": "2016-Datacenter-smalldisk",
"version": "latest"
},
"hardwareProfile": {
"vmSize": "Standard_DS2_v2"
}
},
"osProfile": {
"computerNamePrefix": "myvirtualmachine",
"adminUsername": "azureuser",
"adminPassword": "P@ssw0rd!"
}
}
}
Restablecimiento de la imagen inicial de una máquina virtual mediante

REST
Puede restablecer la imagen inicial de una instancia de máquina virtual con un disco de sistema operativo efímero
mediante la API REST, como se describe a continuación y mediante Azure Portal en el panel Información general
de la máquina virtual. Para los conjuntos de escalado, el restablecimiento de la imagen inicial ya está disponible
mediante PowerShell, la CLI y el portal.
POST https://management.azure.com/subscriptions/{sub-
id}/resourceGroups/{rgName}/providers/Microsoft.Compute/VirtualMachines/{vmName}/reimage?a pi-version=2018-06-
01"

P: ¿Cuál es el tamaño de los discos del sistema operativo locales?
R: Admitiremos la plataforma o las imágenes personalizadas, hasta el tamaño de caché de la máquina virtual,
donde todas las operaciones de lectura y escritura en el disco del sistema operativo serán locales en el mismo nodo
que la máquina virtual.
P: ¿Se puede cambiar el tamaño del disco del sistema operativo efímero?
R: No, una vez que se aprovisiona el disco del sistema operativo efímero, no puede cambiarse su tamaño.
P: ¿Puedo asociar un disco administrado a una máquina virtual efímera?
R: Sí, puede asociar un disco de datos administrado a una máquina virtual que use un disco del sistema operativo
efímero.
P: ¿Se admitirán todos los tamaños de máquina virtual con los discos del sistema operativo efímeros?
R: No, se admiten todos los tamaños de máquina virtual Premium Storage (DS, ES, FS, GS y M ), excepto los
tamaños de las series B, N y H.
P: ¿Se puede aplicar el disco del sistema operativo efímero a máquinas virtuales y conjuntos de escalado
existentes?
R: No, el disco del sistema operativo efímero solo se puede usar durante la creación de la máquina virtual y el
conjunto de escalado.
P: ¿Se pueden combinar discos del sistema operativo efímeros y normales en un conjunto de escalado?
R: No, no se puede tener una combinación de instancias de disco del sistema operativo efímeras y persistentes
dentro del mismo conjunto de escalado.
P: ¿Se puede crear el disco del sistema operativo efímero con PowerShell o la CLI?
R: Sí, puede crear máquinas virtuales con discos del sistema operativo efímeros mediante REST, plantillas,
PowerShell y la CLI.
P: ¿Qué características no se admiten con los discos del sistema operativo efímeros?
R: Los discos efímeros no admiten:
Captura de imágenes de máquina virtual
Instantáneas de disco.
Azure Backup
Azure Site Recovery
Intercambio de discos del sistema operativo
Pasos siguientes
Puede crear una máquina virtual con un disco de SO efímero mediante Azure PowerShell.
Redes virtuales y máquinas virtuales en Azure
Cuando se crea una máquina virtual (VM ) de Azure, es preciso crear una red virtual (VNet) o usar una red virtual
existente. También es preciso decidir la forma en que pretende que se acceda a las máquinas virtuales en la red
virtual. Es importante planear antes de crear recursos y asegurarse de que se conocen los límites de los recursos de
red.
En la siguiente ilustración, las máquinas virtuales se representan como servidores web y servidores de base de
datos. Cada conjunto de máquinas virtuales se asignan a subredes separadas en la red virtual.
Puede crear una red virtual antes de crear una máquina virtual, o bien hacerlo al crearla. Para que se pueda
establecer comunicación con una máquina virtual, debe crear estos recursos:
Interfaces de red
Direcciones IP
Red virtual y subredes
Además de estos recursos básicos, también debe considerar estos recursos opcionales:
Grupos de seguridad de red
Equilibradores de carga
NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module (Presentación
del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az, consulte
Instalación de Azure PowerShell.
Interfaces de red
Una interfaz de red (NIC ) es la interconexión entre una máquina virtual y una red virtual (VNet). Una máquina
virtual debe tener al menos una NIC, pero puede tener varias, en función del tamaño de la máquina virtual que se
cree. Más información sobre cuántas NIC admite cada tamaño de máquina virtual Windows o Linux.
Puede crear una máquina virtual con varias NIC y agregarlas o quitarlas a lo largo del ciclo de vida de una
máquina virtual. Disponer de varias NIC permite a una máquina virtual conectarse a distintas subredes y enviar o
recibir tráfico a través de la interfaz más adecuada. Puede haber máquinas virtuales con cualquier cantidad de
interfaces de red en el mismo conjunto de disponibilidad, hasta el máximo que permita el tamaño de la máquina
virtual.
Todas las NIC conectadas a una máquina virtual deben existir en la misma ubicación y suscripción que esta. Cada
NIC debe estar conectada a una red virtual que exista en la misma ubicación y suscripción de Azure en la que se
encuentre la NIC. Una vez creada la NIC, puede cambiar la subred a la que la máquina virtual está conectada, pero
no la red virtual. A cada NIC conectada a una máquina virtual se le asigna una dirección MAC que no cambia hasta
que se elimine la máquina virtual.
En esta tabla se enumeran los métodos que se pueden usar para crear una interfaz de red.
Portal de Azure Cuando se crea una máquina virtual en Azure Portal, se crea
automáticamente una interfaz de red (no se puede usar una
NIC que se cree de manera independiente). El portal crea una
máquina virtual con una sola NIC. Si desea crear una máquina
virtual con más de una, debe usar otro método para hacerlo.
Azure PowerShell Use New-AzNetworkInterface con el parámetro -

PublicIpAddressId para proporcionar el identificador de la
dirección IP pública que creó anteriormente.
CLI de Azure Para proporcionar el identificador de la dirección IP pública

que creó anteriormente, use az network nic create con el
parámetro --public-ip-address.
Plantilla Use Network Interface in a Virtual Network with Public IP

Address (Interfaz de red en una red virtual con dirección IP
pública) como guía para implementar una interfaz de red
mediante una plantilla.
Direcciones IP
En Azure se pueden asignar estos tipos de direcciones IP a una NIC:
Direcciones IP públicas: se usan para la comunicación entrante y saliente [sin traducción de direcciones de
red (NAT)] con Internet y otros recursos de Azure no conectados a una red virtual. La asignación de una
dirección IP pública a una NIC es opcional. Las direcciones IP públicas tienen un cargo nominal y se puede usar
un número máximo de ellas por suscripción.
Direcciones IP privadas: se usan para la comunicación dentro de una red virtual, una red local e Internet (con
NAT). Debe asignar al menos una dirección IP privada a una máquina virtual. Para más información acerca de
NAT en Azure, lea Información sobre las conexiones salientes en Azure.
Las direcciones IP públicas se pueden asignar a las máquinas virtuales o a los equilibradores de carga con acceso a
Internet. Las direcciones IP privadas se pueden asignar a las máquinas virtuales y a los equilibradores de carga
internos. Las direcciones IP se asignan a una máquina virtual mediante una interfaz de red.
Existen dos métodos en los que se asigna una dirección IP a un recurso: dinámico o estático. El predeterminado es
el dinámico, en el que no se asigna ninguna dirección IP durante la creación. En su lugar, la dirección IP se asigna
cuando se crea una máquina virtual o se inicia una máquina virtual detenida. La dirección IP se libera cuando se
detiene o se elimina la máquina virtual.
Para asegurarse de que la dirección IP de la máquina virtual no cambia, puede establecer explícitamente el método
de asignación en estático. En este caso, se asigna de inmediato una dirección IP. Solo se libera cuando se elimina la
máquina virtual o cuando se cambia su método de asignación a dinámico.
En esta tabla se enumeran los métodos que se pueden usar para crear una dirección IP.
Azure Portal De manera predeterminada, las direcciones IP públicas son

dinámicas y la dirección asociada a ellas puede cambiar cuando
la máquina virtual se detiene o elimina. Para garantizar que la
máquina virtual siempre usa la misma dirección IP pública,
cree una dirección IP pública estática. De manera
predeterminada, el portal asigna una dirección IP privada
dinámica a una NIC al crear una máquina virtual. Una vez
creada esta, puede cambiar la dirección IP a estática.
Azure PowerShell Use New-AzPublicIpAddress con el parámetro -

AllocationMethod como Dynamic o Static.
CLI de Azure Use az network public-ip create con el parámetro --

allocation-method como Dynamic o Static.
Plantilla Use Network Interface in a Virtual Network with Public IP

Address (Interfaz de red en una red virtual con dirección IP
pública) como guía para implementar una dirección IP pública
mediante una plantilla.
Después de crear una dirección IP pública, se puede asociar a una máquina virtual. Para ello, es preciso asignarla a
una NIC.

Una subred es un intervalo de direcciones IP en la red virtual. Una red virtual se puede dividir en varias subredes
para facilitar su organización o por motivos de seguridad. Cada una de las NIC de una máquina virtual está
conectada a una subred de una red virtual. Las NIC conectadas a subredes (iguales o distintas) dentro de una red
virtual pueden comunicarse entre sí sin ninguna configuración adicional.
Al configurar una red virtual, especifique la topología, incluidos los espacios de direcciones y las subredes
disponibles. Si la red virtual se va a conectar a otras redes virtuales o a redes locales, es preciso seleccionar
intervalos de direcciones que no se superpongan. Las direcciones IP son privadas y no se puede acceder a ellas
desde Internet, lo cual sucedía solo en el caso de las direcciones IP no enrutables como 10.0.0.0/8, 172.16.0.0/12 o
192.168.0.0/16. Ahora, Azure trata todos los intervalos de direcciones como parte del espacio de direcciones IP de
redes virtuales privadas al que solo se puede acceder dentro de la red virtual, de redes virtuales interconectadas y
desde su ubicación local.
Si trabaja en una organización en la que otra persona es responsable de las redes internas, póngase en contacto
con ella antes de seleccionar el espacio de direcciones. Asegúrese de que no se superpone a otro e infórmele acerca
del espacio que desea usar, con el fin de que no intente usar el mismo intervalo de direcciones IP.
De forma predeterminada, no hay ningún límite de seguridad entre subredes, por lo que las máquinas virtuales de
cada una de estas subredes pueden comunicarse entre sí. Sin embargo, se pueden configurar grupos de seguridad
de red (NSG ), que permiten controlar el flujo de tráfico que llega y sale tanto de las subredes como de las
En esta tabla se enumeran los métodos que se pueden usar para crear una red virtual y subredes.
Azure Portal Si deja que Azure cree una red virtual cuando cree una
máquina virtual, el nombre será una combinación del nombre
del grupo de recursos que contiene la red virtual y - vnet. El
espacio de direcciones será 10.0.0.0/24, el nombre de subred
requerida será default y el intervalo de direcciones de la
subred será 10.0.0.0/24.
Azure PowerShell Para crear una subred y una red virtual se usan New-
AzVirtualNetworkSubnetConfig y New-AzVirtualNetwork.
También se puede usar Add-AzVirtualNetworkSubnetConfig
para agregar una subred a una red virtual existente.
CLI de Azure La subred y la red virtual se crean al mismo tiempo.

Especifique el parámetro --subnet-name en az network vnet
create con el nombre de la subred.
Plantilla La manera más fácil de crear una red virtual y subredes es

descargar una plantilla existente, como Virtual Network with
two Subnets (Red virtual con dos subredes) y modificarla hasta
ajustarla a sus necesidades.

Un grupo de seguridad de red (NSG ) contiene una lista de reglas de la lista de control de acceso (ACL ) que
permiten o deniegan el tráfico de red a subredes, NIC, o ambas. Los grupos de seguridad de red se pueden asociar
con subredes o con NIC individuales conectadas a una subred. Si un grupo de seguridad de red está asociado a
una subred, las reglas de la ACL se aplican a todas las máquinas virtuales de dicha subred. Además, se puede
limitar el tráfico que llega a una NIC individual, para lo que se debe asociar un NSG directamente a la NIC.
Contiene dos tipos de reglas: de entrada y de salida. La prioridad de una regla debe ser única dentro de cada
conjunto. Cada regla tiene propiedades de protocolo, intervalos de puertos de origen y destino, prefijos de
direcciones, dirección de tráfico, prioridad y tipo de acceso.
Todos los grupos de seguridad de red contienen un conjunto de reglas predeterminadas. No se pueden eliminar las
reglas predeterminadas, pero dado que tienen asignada la mínima prioridad, pueden reemplazarse por las reglas
que cree.
Al asociar un grupo de seguridad de red a una NIC, las reglas de acceso de red del grupo de seguridad de red se
aplican solo a esa NIC. Si se aplica un grupo de seguridad de red a una sola NIC en una máquina virtual con varias
NIC, el tráfico de las restantes no se verá afectado. Se pueden asociar distintos grupos de seguridad de red a una
NIC (o a una máquina virtual, según el modelo de implementación) y a la subred a la que una NIC o una máquina
virtual están enlazadas. La prioridad depende de la dirección del tráfico.
Cuando planee las máquinas virtuales y red virtual, no olvide planear los grupos de seguridad de red.
En esta tabla se enumeran los métodos que se pueden usar para crear un grupo de seguridad de red.
Azure Portal Cuando se crea una máquina virtual en Azure Portal, se crea
automáticamente un grupo de seguridad de red, que se asocia
a la NIC que crea el portal. El nombre de dicho grupo es una
combinación del nombre de la máquina virtual y - nsg. Este
grupo de seguridad de red contiene una regla de entrada con
una prioridad de 1000, un servicio establecido en RDP, el
protocolo establecido en TCP, el puerto establecido en 3389 y
la acción establecida en Allow (Permitir). Si desea permitir que
otro tráfico de entrada a la máquina virtual, debe agregar más
reglas al NSG.
Azure PowerShell Use New-AzNetworkSecurityRuleConfig y especifique la

información de las reglas requerida. Use New-
AzNetworkSecurityGroup para crear el grupo de seguridad de
red. Use Set-AzVirtualNetworkSubnetConfig para configurar el
grupo de seguridad de red para la subred. Use Set-
AzVirtualNetwork para agregar el grupo de seguridad de red a
la red virtual.
CLI de Azure Use az network nsg create para crear inicialmente el grupo de
seguridad de red. Use az network nsg rule create para agregar
reglas al grupo de seguridad de red. Use az network vnet
subnet update para agregar el grupo de seguridad de red a la
subred.
Plantilla Use Create a Network Security Group (Creación de un grupo

de seguridad de red) como guía para la implementación de un
grupo de seguridad de red mediante una plantilla.
Azure Load Balancer proporciona una alta disponibilidad y un elevado rendimiento de red a las aplicaciones. Se
puede configurar un equilibrador de carga para equilibrar el tráfico entrante de Internet a las máquinas virtuales o
equilibrar el tráfico entre las máquinas virtuales de una red virtual. Un equilibrador de carga también puede
equilibrar el tráfico entre los equipos locales y las máquinas virtuales de una red entre entornos, o reenviar el
tráfico externo a una máquina virtual concreta.
El equilibrador de carga asigna el tráfico entrante y saliente entre la dirección IP pública y el puerto del
equilibrador de carga y la dirección IP privada y puerto de la máquina virtual.
Al crear un equilibrador de carga, también es preciso tener en cuenta estos elementos de configuración:
Configuración de IP de front-end: un equilibrador de carga puede incluir una o varias direcciones IP de
front-end, conocidas también como IP virtuales (VIP ). Estas direcciones IP sirven como entrada para el tráfico.
Grupo de direcciones de back-end: direcciones IP que están asociadas a la NIC a la que se distribuye la
carga.
Reglas NAT: define el flujo del tráfico entrante a través de la IP de front-end y su distribución a la IP de back-
end.
Reglas del equlibrador de carga: asigna una combinación dada de IP de front-end y puerto a una
combinación de un conjunto de direcciones IP de back-end y puerto. Un solo equilibrador de carga puede tener
varias reglas de equilibrio de carga. Cada regla tiene una combinación de una IP de front-end y un puerto y una
IP de back-end asociados a las máquinas virtuales.
Sondeos : supervisa el estado de las máquinas virtuales. Si un sondeo no responde, el equilibrador de carga
deja de enviar nuevas conexiones a la máquina virtual que no funciona correctamente. Las conexiones
existentes no resultan afectadas y las nuevas conexiones se envían a las máquinas virtuales que están en buen
estado.
En esta tabla se enumeran los métodos que se pueden usar para crear un equilibrador de carga con acceso a
Internet.
Portal de Azure Puede equilibrar la carga del tráfico de Internet en máquinas

virtuales mediante Azure Portal.
Azure PowerShell Para proporcionar el identificador de la dirección IP pública

que creó anteriormente, use New-
AzLoadBalancerFrontendIpConfig con el parámetro -
PublicIpAddress. Use New-
AzLoadBalancerBackendAddressPoolConfig para crear la
configuración del grupo de direcciones de back-end. Use New-
AzLoadBalancerInboundNatRuleConfig para crear reglas NAT
de entrada asociadas a la configuración de la IP de front-end
que ha creado. Use New-AzLoadBalancerProbeConfig para
crear los sondeos que necesite. Use New-
AzLoadBalancerRuleConfig para crear la configuración del
equilibrador de carga. Use New-AzLoadBalancer para crear el
CLI de Azure Use az network lb create para crear la configuración inicial del
equilibrador de carga. Use az network lb frontend-ip create
para agregar la dirección IP pública que creó anteriormente.
Use az network lb address-pool create para agregar la
configuración del grupo de direcciones de back-end. Use az
network lb inbound-nat-rule create para agregar reglas NAT.
Use az network lb rule create para agregar las reglas del
equilibrador de carga. Use az network lb probe create para
agregar los sondeos.
Plantilla Use 2 VMs in a Load Balancer and configure NAT rules on the
LB (Dos máquinas virtuales en un equilibrador de carga y
configurar reglas NAT en el equilibrador de carga) como guía
para implementar un equilibrador de carga mediante una
plantilla.
En esta tabla se enumeran los métodos que se pueden usar para crear un equilibrador de carga interno.
Portal de Azure Puede equilibrar la carga de tráfico interno con un equilibrador

de carga básico en Azure Portal.
Azure PowerShell Para proporcionar una dirección IP privada en la subred de la

red, utilice New-AzLoadBalancerFrontendIpConfig con el
parámetro -PrivateIpAddress. Use New-
AzLoadBalancerBackendAddressPoolConfig para crear la
configuración del grupo de direcciones de back-end. Use New-
AzLoadBalancerInboundNatRuleConfig para crear reglas NAT
de entrada asociadas a la configuración de la IP de front-end
que ha creado. Use New-AzLoadBalancerProbeConfig para
crear los sondeos que necesite. Use New-
AzLoadBalancerRuleConfig para crear la configuración del
equilibrador de carga. Use New-AzLoadBalancer para crear el
CLI de Azure Use el comando az network lb create para crear la

configuración inicial del equilibrador de carga. Para definir la
dirección IP privada, utilice az network lb frontend-ip create
con el parámetro --private-ip-address. Use az network lb
address-pool create para agregar la configuración del grupo
de direcciones de back-end. Use az network lb inbound-nat-
rule create para agregar reglas NAT. Use az network lb rule
create para agregar las reglas del equilibrador de carga. Use az
network lb probe create para agregar los sondeos.
Plantilla Use 2 VMs in a Load Balancer and configure NAT rules on the
LB (Dos máquinas virtuales en un equilibrador de carga y
configurar relas NAT en el equilibrador de carga) como guía
para implementar un equilibrador de carga mediante una
plantilla.
Máquinas virtuales
Las máquinas virtuales se pueden crear en la misma red virtual y se pueden conectar entre sí mediante direcciones
IP privadas. Pueden conectarse aunque estén en subredes diferentes sin necesidad de configurar una puerta de
enlace o utilizar direcciones IP públicas. Para poner máquinas virtuales en una red virtual, cree la red virtual y,
después, al crear cada máquina virtual, asígnela a la red virtual y la subred. Las máquinas virtuales adquieren su
configuración de red durante la implementación o el inicio.
A las máquinas virtuales se les asigna una dirección IP cuando se implementan. Si implementa varias máquinas
virtuales en una red virtual o una subred, se les asignan direcciones IP cuando arrancan. También puede asignar
una IP estática a una máquina virtual. Si asigna una IP estática, debe plantearse la posibilidad de utilizar una
subred específica para evitar reutilizar accidentalmente una IP estática para otra máquina virtual.
Si crea una máquina virtual y posteriormente desea migrarla a una red virtual, no es un cambio de configuración
simple. Debe volver a implementar la máquina virtual en la red virtual. La manera más fácil de volver a
implementarla es eliminar la máquina virtual, pero no los discos conectados a ella y, después, volver a crear la
máquina virtual con los discos originales en la red virtual.
En esta tabla se enumeran los métodos que se pueden usar para crear una máquina virtual en una red virtual.
Azure Portal Utiliza la configuración de red predeterminada que se

mencionó anteriormente para crear una máquina virtual con
una NIC única. Para crear una máquina virtual con varias NIC,
es preciso usar otro método.
Azure PowerShell Incluye el uso de Add-AzVMNetworkInterface para agregar la

NIC que creó anteriormente a la configuración de la VM.
CLI de Azure Cree y conecte una máquina virtual a una red virtual, subred y
NIC creadas mediante pasos individuales.
Plantilla Use Very simple deployment of a Windows VM

(Implementación muy simple de una máquina virtual
Windows) como guía para la implementación de una máquina
virtual mediante una plantilla.
Pasos siguientes
Para conocer los pasos específicos para máquinas virtuales sobre cómo administrar redes virtuales de Azure en
máquinas virtuales, consulte los tutoriales de Windows o Linux.
También hay tutoriales sobre cómo equilibrar la carga de las máquinas virtuales y crear aplicaciones de alta
disponibilidad para Windows o Linux.
Aprenda a configurar rutas definidas por el usuario y el reenvío IP.
Aprenda a configurar conexión de red virtual a red virtual.
Aprenda a solucionar problemas de rutas.
¿Qué son los conjuntos de escalado de máquina
virtual?
Los conjuntos de escalado de máquinas virtuales de Azure permiten crear y administrar un grupo de máquinas
virtuales idénticas con equilibrio de carga y ajuste automático. El número de instancias de máquina virtual puede
aumentar o disminuir automáticamente según la demanda, o de acuerdo a una programación definida. Los
conjuntos de escalado proporcionan una alta disponibilidad a las aplicaciones y le permiten administrar, configurar
y actualizar de forma centralizada un gran número de máquinas virtuales. Con los conjuntos de escalado de
máquinas virtuales, puede crear servicios a gran escala para áreas como proceso, macrodatos y cargas de trabajo
de contenedor.
¿Por qué utilizar conjuntos de escalado de máquinas virtuales?

Para proporcionar redundancia y mejorar el rendimiento las aplicaciones normalmente se distribuyen entre varias
instancias. Los clientes pueden acceder a la aplicación mediante un equilibrador de carga que distribuye las
solicitudes a una de las instancias de la aplicación. Si necesita realizar tareas de mantenimiento o actualizar una
instancia de la aplicación, los clientes tienen que distribuirse a otra instancia de aplicación que esté disponible. Para
hacer frente a la demanda adicional de los clientes, puede que tenga que aumentar el número de instancias de
aplicación en las que se ejecuta la aplicación.
Los conjuntos de escalado de máquinas virtuales de Azure proporcionan las capacidades de administración para
las aplicaciones que se ejecutan en varias máquinas virtuales, el escalado automático de recursosy el equilibrio de
carga de tráfico. Los conjuntos de escalado ofrecen las siguientes ventajas principales:
Facilitan la creación y administración de varias máquinas virtuales
Cuando tiene muchas máquinas virtuales que ejecutan la aplicación es importante mantener una
configuración coherente en todo el entorno. Para obtener un rendimiento confiable de la aplicación, el
tamaño de máquina virtual, la configuración de disco y las instalaciones de la aplicación deben coincidir
en todas las máquinas virtuales.
Con los conjuntos de escalado se crean todas las instancias de máquina virtual desde la misma
configuración e imagen base de sistema operativo. Este enfoque le permite administrar fácilmente
cientos de máquinas virtuales sin tareas adicionales de configuración o administración de red.
Los conjuntos de escalado admiten el uso de Azure Load Balancer para la distribución del tráfico de nivel
4 básico, y de Azure Application Gateway para las características más avanzadas de distribución de nivel
7 y terminación SSL.
Proporcionan alta disponibilidad y resistencia de aplicación
Los conjuntos de escalado se utilizan para ejecutar varias instancias de la aplicación. Si una de estas
instancias de máquina virtual tiene un problema, los clientes siguen teniendo acceso a la aplicación a
través de una de las otras instancias de máquina virtual con una interrupción mínima.
Con el fin de tener mayor disponibilidad, puede usar zonas de disponibilidad para distribuir
automáticamente las instancias de máquina virtual en un conjunto de escalado dentro de un único centro
de datos o en varios centros de datos.
Permiten a la aplicación escalar automáticamente a medida que cambia la demanda de recursos
La demanda de la aplicación por parte de los clientes puede cambiar a lo largo del día o de la semana.
Para cumplir con la demanda del cliente, los conjuntos de escalado pueden aumentar o disminuir
automáticamente el número de instancias de máquina virtual a medida que aumenta o disminuye la
demanda de la aplicación.
El escalado automático reduce el número de instancias innecesarias de máquina virtual que ejecutan la
aplicación cuando la demanda es baja, mientras que cuando la demanda aumenta, los clientes continúan
recibiendo un nivel aceptable de rendimiento gracias a la incorporación automática de instancias
adicionales de máquina virtual. Esta capacidad le ayuda a reducir los costos y a crear de forma eficaz los
recursos de Azure según sea necesario.
Funciona a gran escala
Los conjuntos de escalado admiten hasta 1000 instancias de máquina virtual. Si crea y carga sus propias
imágenes de máquina virtual personalizadas, el límite es 600 instancias.
Para el mejor rendimiento con cargas de trabajo de producción, use Azure Managed Disks.
Diferencias entre las máquinas virtuales y los conjuntos de escalado

Los conjuntos de escalado se generan a partir de máquinas virtuales. Con los conjuntos de escalado las capas de
administración y automatización sirven para ejecutar y escalar sus aplicaciones. En su lugar podría crear y
administrar manualmente máquinas virtuales individuales, o integrar herramientas existentes para crear un nivel
similar de automatización. En la tabla siguiente se describen las ventajas de los conjuntos de escalado en
comparación con la administración manual de varias instancias de máquina virtual.
GRUPO MANUAL DE MÁQUINAS CONJUNTO DE ESCALADO DE MÁQUINA

ESCENARIO VIRTUALES VIRTUAL
Incorporación de instancias adicionales Proceso manual para crear, configurar y Creación automática a partir de la
de máquina virtual garantizar el cumplimiento configuración central
Equilibrio y distribución del tráfico Proceso manual para crear y configurar Posibilidad de crear e integrar
una instancia de Azure Load Balancer o automáticamente con Azure Load
Application Gateway Balancer o Application Gateway
Alta disponibilidad y redundancia Creación manual de conjuntos de Distribución automática de instancias de

disponibilidad o distribución y máquina virtual a través de las zonas de
seguimiento manual de las máquinas disponibilidad o conjuntos de
virtuales en las distintas zonas de disponibilidad
disponibilidad
Escalado de máquinas virtuales Supervisión manual y Azure Automation Escalado automático basado en las
métricas de host, las métricas de
invitado, Application Insights o
programación
No hay costo adicional por usar conjuntos de escalado. Solo se paga por los recursos de proceso subyacente como
las instancias de máquina virtual, el equilibrador de carga o el almacenamiento de disco administrado. Las
características de administración y automatización, como el escalado automático y la redundancia, no incurren en
cargos adicionales sobre el uso de máquinas virtuales.
Cómo supervisar los conjuntos de escalado

Use Azure Monitor para VM, que tiene un proceso de incorporación sencillo y automatiza la recopilación de
contadores de rendimiento de CPU, memoria, disco y red importantes de las máquinas virtuales en el conjunto de
escalado. También incluye funcionalidades de supervisión adicionales y visualizaciones predefinidas que le ayudan
a centrarse en la disponibilidad y el rendimiento de los conjuntos de escalado.
Habilite la supervisión de la aplicación del conjunto de escalado de máquinas virtuales con Application Insights
para recopilar la información detallada acerca de la aplicación, como vistas de página, solicitudes de aplicación y
excepciones. Compruebe de forma más exhaustiva la disponibilidad de la aplicación configurando una prueba de
disponibilidad para simular el tráfico de usuarios.
Pasos siguientes
Para empezar cree su primer conjunto de escalado de máquinas virtuales en Azure Portal.
Creación de un conjunto de escalado en Azure Portal
Uso de herramientas de automatización de la
infraestructura con máquinas virtuales de Azure
Para crear y administrar máquinas virtuales (VM ) de Azure de manera coherente a escala, suele ser deseable
alguna forma de automatización. Existen muchas herramientas y soluciones que le permiten automatizar la
implementación de toda la infraestructura de Azure y el ciclo de vida de administración. En este artículo se detallan
algunas de las herramientas de automatización de la infraestructura que puede usar en Azure. Estas herramientas
se adaptan normalmente a alguno de los siguientes enfoques:
Automatización de la configuración de las máquinas virtuales
Estas herramientas incluyen Ansible, Chef y Puppet.
Entre las herramientas específicas para la personalización de máquinas virtuales se incluye cloud-init
para máquinas virtuales Linux, PowerShell Desired State Configuration (DSC ) y la extensión de script
personalizado de Azure para todas las máquinas virtuales de Azure.
Automatización de la administración de la infraestructura
Entre las herramientas se incluye Packer para automatizar las compilaciones personalizadas de imágenes
de máquina virtual, y Terraform para automatizar el proceso de compilación de la infraestructura.
Azure Automation puede realizar acciones en toda la infraestructura local y de Azure.
Automatización de la implementación y entrega de aplicaciones
Algunos ejemplos son Azure DevOps Services y Jenkins.
Ansible
Ansible es un motor de automatización para la administración de configuraciones, la creación de máquinas
virtuales o la implementación de aplicaciones. Ansible utiliza un modelo sin agente, normalmente con claves SSH,
para autenticar y administrar las máquinas de destino. Las tareas de configuración se definen en cuadernos de
estrategias, con una serie de módulos de Ansible disponibles para llevar a cabo tareas específicas. Para más
información, consulte el funcionamiento de Ansible.
Obtenga información sobre cómo:
Instalar y configurar Ansible en Linux para su uso con Azure.
Crear una máquina virtual Linux.
Administrar una máquina virtual Linux.
Chef
Chef es una plataforma de automatización que ayuda a definir cómo se configura, implementa y administra la
infraestructura. Entre los componentes adicionales se incluye Chef Habitat para la automatización del ciclo de vida
de la aplicación más que de la infraestructura, y Chef InSpec que ayuda a automatizar el cumplimiento normativo
con los requisitos de seguridad o de directiva. Los clientes de Chef se instalan en las máquinas de destino, con uno
o varios servidores de Chef centrales que almacenan y administran las configuraciones. Para más información,
consulte la introducción a Chef.
Implementar Chef Automate desde Azure Marketplace.
Instalar Chef en Windows y crear máquinas virtuales de Azure.
Puppet
Puppet es una plataforma de automatización preparada para la empresa que controla el proceso de entrega e
implementación de la aplicación. Los agentes se instalan en las máquinas de destino para permitir a Puppet Master
ejecutar los manifiestos que definen la configuración deseada de la infraestructura y las máquinas virtuales de
Azure. Puppet puede integrarse con otras soluciones como Jenkins y GitHub para obtener un flujo de trabajo de
DevOps mejorado. Para más información, consulte el funcionamiento de Puppet.
Implementar Puppet desde Azure Marketplace.
Cloud-Init
cloud-init es un enfoque ampliamente usado para personalizar una máquina virtual Linux la primera vez que se
arranca. Puede usar cloud-init para instalar paquetes y escribir archivos o para configurar los usuarios y la
seguridad. Dado que se llama a cloud-init durante el proceso de arranque inicial, no se necesitan pasos adicionales
ni agentes para aplicar la configuración. Para más información sobre cómo dar formato correctamente a sus
archivos #cloud-config , consulte el sitio de documentación de cloud-init. Los archivos #cloud-config son archivos
de texto codificados en base64.
cloud-init también funciona entre distribuciones. Por ejemplo, no use apt-get install o yum install para instalar
un paquete. En su lugar, puede definir una lista de paquetes que se van a instalar.Cloud-init usará automáticamente
la herramienta de administración de paquetes nativos para la distribución de Linux (distro) que seleccione.
Estamos trabajando activamente con nuestros asociados de distribuciones de Linux certificadas para disponer de
imágenes con cloud-init habilitado en Azure Marketplace. Estas imágenes harán que las implementaciones y
configuraciones de cloud-init funcionen perfectamente con las máquinas virtuales y los conjuntos de escalado de
máquinas virtuales. Obtener información más detallada sobre cloud-init en Azure:
Compatibilidad con cloud-init para máquinas virtuales Linux en Azure
Consulte el tutorial sobre configuración automatizada de máquinas virtuales con cloud-init.
PowerShell DSC
PowerShell Desired State Configuration (DSC ) es una plataforma de administración que se usa para definir la
configuración de las máquinas de destino. DSC también se puede utilizar en Linux mediante el servidor de
infraestructura de administración abierta (OMI).
Las configuraciones de DSC definen lo que se debe instalar en una máquina y cómo configurar el host. Un motor
de administración de configuración local (LCM ) se ejecuta en cada nodo de destino que procesa las acciones
requeridas en función de las configuraciones insertadas. Un servidor de extracción es un servicio web que se
ejecuta en un host central para almacenar las configuraciones de DSC y los recursos asociados. El servidor de
extracción se comunica con el motor de LCM en cada host de destino para proporcionar las configuraciones
necesarias e informar sobre el cumplimiento.
Crear una configuración básica de DSC.
Configurar un servidor de extracción de DSC.
Usar DSC para Linux.
Extensión de script personalizado de Azure

La extensión de script personalizado para Linux o Windows descarga y ejecuta scripts en máquinas virtuales de
Azure. Puede utilizar la extensión al crear una máquina virtual o en cualquier momento después de empezar a
usarla.
Los scripts se pueden descargar desde Azure Storage o desde cualquier ubicación pública como, por ejemplo, un
repositorio de GitHub. Con la extensión de script personalizado, puede escribir scripts en cualquier lenguaje que se
pueda ejecutar en la máquina virtual de origen. Estos scripts se pueden usar para instalar aplicaciones o configurar
la máquina virtual según sea necesario. Para proteger las credenciales, la información confidencial como las
contraseñas se puede almacenar en una configuración protegida. Estas credenciales solo se descifran dentro de la
máquina virtual.
Crear una máquina virtual Linux con la CLI de Azure y usar la extensión de script personalizado.
Crear una máquina virtual Windows con Azure PowerShell y usar la extensión de script personalizado.
Packer
Packer automatiza el proceso de compilación cuando se crea una imagen personalizada de la máquina virtual en
Azure. Puede usar Packer para definir el sistema operativo y ejecutar scripts posteriores a la configuración que
permiten personalizar la máquina virtual según sus necesidades específicas. Una vez terminada la configuración, la
máquina virtual se captura como una imagen de Manage Disks. Packer automatiza el proceso para crear la
máquina virtual de origen, la red y los recursos de almacenamiento, ejecutar los scripts de configuración y,
finalmente, crear la imagen de la máquina virtual.
Usar Packer para crear una imagen de máquina virtual Linux en Azure.
Usar Packer para crear una imagen de máquina virtual Windows en Azure.
Terraform
Terraform es una herramienta de automatización que le permite definir y crear una infraestructura de Azure
completa con un lenguaje de formato de plantilla única: el lenguaje de configuración de HashiCorp (HCL ). Con
Terraform, puede definir las plantillas que automatizan el proceso de creación de los recursos de la red, del
almacenamiento y de la máquina virtual para una solución de aplicación determinada. Puede utilizar las plantillas
de Terraform existentes para otras plataformas con Azure para garantizar la coherencia y simplificar la
implementación de la infraestructura sin necesidad de convertirlas a una plantilla de Azure Resource Manager.
Instalar y configurar Terraform con Azure.
Crear una infraestructura de Azure con Terraform.
Azure Automation
Azure Automation usa runbooks para procesar un conjunto de tareas en las máquinas virtuales de su elección.
Azure Automation se usa para administrar las máquinas virtuales existentes en lugar de para crear una
infraestructura. Azure Automation puede ejecutarse en máquinas virtuales Linux y Windows, así como en
máquinas virtuales o físicas locales con una instancia de Hybrid Runbook Worker. Los runbooks se pueden
almacenar en un repositorio de control de código fuente como GitHub. Estos runbooks se pueden ejecutar
manualmente o según una programación definida.
Azure Automation también proporciona un servicio Desired State Configuration (DSC ) que le permite crear
definiciones para configurar un conjunto determinado de máquinas virtuales. DSC garantiza que se aplica la
configuración necesaria y que la máquina virtual sigue siendo coherente. DSC de Automatización de Azure se
puede ejecutar tanto en máquinas virtuales Windows como Linux.
Crear un runbook de PowerShell.
Usar Hybrid Runbook Worker para administrar recursos locales.
Usar DSC de Automatización de Azure.
Azure DevOps Services

Azure DevOps Services es un conjunto de herramientas que le ayudarán a compartir y realizar un seguimiento del
código, usar compilaciones automatizadas y crear una canalización de desarrollo e integración continua (CI/CD )
completa. Azure DevOps Services se integra con Visual Studio y otros editores para facilitar el uso. Azure DevOps
Services también puede crear y configurar máquinas virtuales de Azure e implementar código en ellas.
Más información sobre:
Azure DevOps Services.
Jenkins
Jenkins es un servidor de integración continua que ayuda a implementar y probar aplicaciones, y a crear
canalizaciones automatizadas para la entrega de código. Existen cientos de complementos para ampliar la
plataforma principal de Jenkins y también lo puede integrar con muchos otros productos y soluciones mediante los
webhooks. Puede instalar Jenkins de forma manual en una máquina virtual de Azure, ejecutar Jenkins desde
dentro de un contenedor de Docker o utilizar una imagen de Azure Marketplace que se haya creado previamente.
Crear una infraestructura de desarrollo en una máquina virtual Linux en Azure con Jenkins, GitHub y Docker.
Pasos siguientes
Hay muchas opciones diferentes para utilizar herramientas de automatización de infraestructura en Azure. Es libre
de elegir la solución que mejor se adapte a sus necesidades y entorno. Para empezar a trabajar y probar algunas de
las herramientas integradas en Azure, vea cómo automatizar la personalización de una máquina virtual Linux o
Windows.
Protección y uso de directivas en máquinas virtuales
en Azure
Es importante proteger la máquina virtual (VM ) para las aplicaciones que se ejecutan. Proteger las máquinas
virtuales puede suponer que se incluyan uno o varios servicios y características de Azure que abarcan un acceso
seguro a las máquinas virtuales y al almacenamiento seguro de los datos. Este artículo proporciona información
que le permite proteger las máquinas virtuales y las aplicaciones.
Antimalware
El panorama moderno de amenazas para los entornos de nube es dinámico, lo que aumenta la presión para
mantener una protección eficaz a fin de satisfacer los requisitos de cumplimiento y seguridad. Microsoft
Antimalware para Azure es una funcionalidad gratuita de protección en tiempo real que ayuda a identificar y
eliminar virus, spyware y otro software malintencionado. Las alertas se pueden configurar para avisarle cuando
software no deseado o malintencionado intenta instalarse o ejecutarse en una máquina virtual. No se admite en las
máquinas virtuales que ejecutan Linux o Windows Server 2008.
Azure Security Center

Azure Security Center ayuda a evita y a detectar las amenazas para las máquinas virtuales, además de a responder
a ellas. Security Center proporciona funcionalidades de administración de directivas y supervisión de la seguridad
integradas en las suscripciones de Azure, ayuda a detectar las amenazas que podrían pasar desapercibidas y
funciona con un amplio ecosistema de soluciones de seguridad.
El acceso Just-In-Time de Security Center se puede aplicar en toda la implementación de la máquina virtual para
bloquear el tráfico entrante a las máquinas virtuales de Azure, lo que reduce la exposición a ataques y, al mismo
tiempo, proporciona acceso sencillo para conectarse a las máquinas virtuales cuando sea necesario. Cuando Just-
In-Time está habilitado y un usuario solicita acceso a una máquina virtual, Security Center comprueba qué
permisos tiene el usuario para la máquina virtual. Si tiene los permisos correctos, se aprueba la solicitud y Security
Center configura automáticamente los grupos de seguridad de red (NSG ) para permitir el tráfico entrante a los
puertos seleccionados durante un período de tiempo limitado. Una vez transcurrido ese tiempo, Security Center
restaura los NSG a su estado anterior.
Cifrado
Para mejorar la seguridad y el cumplimiento en las máquinas virtuales Windows y Linux, se pueden cifrar los
discos virtuales en Azure. Los discos virtuales en VM Windows se cifran en reposo mediante BitLocker. Los discos
virtuales en las máquinas virtuales de Linux se cifran en reposo mediante dm-crypt.
El cifrado de los discos virtuales en Azure no conlleva ningún cargo. Las claves criptográficas se almacenan en
Azure Key Vault con protección de software, o puede importar o generar las claves en módulos de seguridad de
hardware (HSM ) certificados conforme a las normas FIPS 140-2 de nivel 2. Las claves criptográficas se usan para
cifrar y descifrar los discos virtuales conectados a la máquina virtual. Estas claves criptográficas se pueden
controlar y se puede auditar su uso. Como las máquinas virtuales se encienden y se apagan, una entidad de
servicio de Azure Active Directory proporciona un mecanismos seguro para la emisión de estas claves
criptográficas.
Key Vault y claves de SSH

Los secretos y los certificados pueden ser modelados como recursos y ser proporcionados por Key Vault. Puede
usar Azure PowerShell para crear almacenes de claves de máquinas virtuales Windows y la CLI de Azure para las
máquinas virtuales Linux. También puede crear claves para el cifrado.
Las directivas de acceso a los almacenes de claves conceden permisos a las claves, los secretos y los certificados
por separado. Por ejemplo, se puede dar a un usuario acceso solo a las claves, pero darle permisos para los
secretos. Sin embargo, los permisos para acceder a las claves, secretos o certificados se encuentran en el nivel del
almacén. En otras palabras, la directiva de acceso de un almacén de claves no admite permisos de nivel de objeto.
Cuando se conecte a máquinas virtuales (VM ), debe usar la criptografía de clave pública para proporcionar una
forma más segura de iniciar sesión en ellas. Este proceso implica un intercambio de claves públicas y privadas
mediante el comando de Secure Shell (SSH) para autenticarse, en lugar de un nombre de usuario y una
contraseña. Las contraseñas son vulnerables a ataques por fuerza bruta, sobre todo en máquinas virtuales con
acceso a Internet, como los servidores web. Con un par de claves de Secure Shell (SSH) puede crear una máquina
virtual Linux en Azure que use claves SSH para la autenticación, lo que elimina la necesidad de usar contraseñas
para iniciar sesión. También puede usar claves de SSH para conectarse desde una máquina virtual Windows a una
máquina virtual Linux.
Identidades administradas de recursos de Azure

Un desafío común al compilar aplicaciones en la nube consiste en el modo de administrar las credenciales del
código para autenticar los servicios en la nube. Proteger las credenciales es una tarea esencial. Lo ideal sería que
nunca aparecieran en las estaciones de trabajo de los desarrolladores y que no se controlaran en el código fuente.
Azure Key Vault proporciona una manera segura de almacenar credenciales, secretos y otras claves pero el código
tiene que autenticarse en Key Vault para recuperarlos.
Las identidades administradas para recursos de Azure con las que cuenta Azure Active Directory (Azure AD )
resuelven este problema. Esta característica proporciona a los servicios de Azure una identidad de sistema
administrada automáticamente en Azure AD. Puede usar esta identidad para autenticarse en cualquier servicio que
admita la autenticación de Azure AD, incluido Key Vault, sin necesidad de credenciales en el código. El código que se
ejecuta en una máquina virtual puede solicitar un token en dos puntos de conexión que solo son accesibles desde
la máquina virtual. Para obtener información detallada acerca de este servicio, revise la página de información
general de identidades administradas para los recursos de Azure.
Directivas
Las directivas de Azure pueden utilizarse para definir el comportamiento deseado de las máquinas virtuales
Windows y de las máquinas virtuales Linux en su organización. Mediante las directivas, una organización puede
aplicar varias convenciones y reglas en toda la empresa. La aplicación del comportamiento deseado puede ayudar
a reducir el riesgo a la vez que se contribuye al éxito de la organización.
Control de acceso basado en rol

Mediante el control de acceso basado en rol (RBAC ), puede repartir las tareas entre el equipo y conceder a los
usuarios únicamente el nivel de acceso que necesitan en la máquina virtual para realizar su trabajo. En lugar de
proporcionar a todos los empleados permisos no restringidos en la máquina virtual, puede permitir solo
determinadas acciones. Puede configurar el control de acceso para la máquina virtual en Azure Portal, usando la
CLI de Azure o Azure PowerShell.
Pasos siguientes
Siga los pasos para supervisar la seguridad de la máquina virtual mediante Azure Security Center para Linux o
Windows.
Azure Disk Encryption para máquinas virtuales
Windows
Azure Disk Encryption ayuda a custodiar y proteger sus datos con el fin de satisfacer los compromisos de
cumplimiento y seguridad de su organización. Usa la característica BitLocker de Windows para proporcionar
cifrado de volumen tanto a los discos de datos como a los del sistema operativo de máquinas virtuales (VM ) de
Azure y se integra con Azure Key Vault para ayudarle a controlar y administrar las claves y los secretos del
cifrado de disco.
Si utiliza Azure Security Center, se le alertará si tiene VM que no estén cifradas. Estas alertas se muestran con
gravedad alta y se recomienda cifrar estas máquinas virtuales.
WARNING
Si ya ha usado Azure Disk Encryption con Azure AD para cifrar una VM, debe seguir usando esta opción para cifrar la
VM. Para más información, consulte Azure Disk Encryption con Azure AD (versión anterior).
Algunas de las recomendaciones pueden provocar un aumento del uso de datos, de la red o de recursos de proceso, lo
que incrementará los costes de las licencias o suscripciones. Para crear recursos en Azure en las regiones admitidas,
debe tener una suscripción válida de Azure activa.
Para obtener información sobre los aspectos básicos de Azure Disk Encryption para Windows en unos minutos,
consulte Inicio rápido: Creación y cifrado de una VM Windows con la CLI de Azure o Inicio rápido: Creación y
cifrado de una VM Windows con Azure Powershell.
VM y sistemas operativos compatibles

Tamaños de máquinas virtuales que se admiten
Las máquinas virtuales Windows están disponibles en una variedad de tamaños. Azure Disk Encryption no está
disponible en VM básicas o de serie A ni en las máquinas virtuales que tengan menos de 2 GB de memoria.
Azure Disk Encryption también está disponible para las VM con almacenamiento Premium.
Sistemas operativos compatibles
Cliente Windows: Windows 8 y versiones posteriores.
Windows Server: Windows Server 2008 R2 y versiones posteriores.
NOTE
Windows Server 2008 R2 requiere la instalación de .NET Framework 4.5 para el cifrado; instálelo desde Windows Update
con la actualización opcional Microsoft .NET Framework 4.5.2 para sistemas basados en Windows Server 2008 R2 x64
(KB2901983).
Windows Server 2012 R2 Core y Windows Server 2016 Core requieren la instalación del componente bdehdcfg en la
máquina virtual para el cifrado.
Requisitos de red
Para habilitar Azure Disk Encryption, las máquinas virtuales deben cumplir los siguientes requisitos de
configuración de los puntos de conexión de red:
Para que un token se conecte a un almacén de claves, la máquina virtual Windows debe poder conectarse a
un punto de conexión de Azure Active Directory, [login.microsoftonline.com].
Para escribir las claves de cifrado en el almacén de claves, la máquina virtual Windows debe poder
conectarse al punto de conexión del almacén de claves.
La máquina virtual Windows debe poder conectarse al punto de conexión de Azure Storage que hospeda el
repositorio de extensiones de Azure y la cuenta de Azure Storage que hospeda los archivos del VHD.
Si su directiva de seguridad limita el acceso desde máquinas virtuales de Azure a Internet, puede resolver el
URI anterior y configurar una regla concreta para permitir la conectividad de salida para las direcciones IP.
Para más información, consulte Azure Key Vault detrás de un firewall.
Requisitos de la directiva de grupo

Azure Disk Encryption usa el protector de claves externas de BitLocker para las máquinas virtuales Windows.
Para las máquinas virtuales unidas en un dominio, no cree ninguna directiva de grupo que exija protectores de
TPM. Para obtener información acerca de la directiva de grupo para "Permitir BitLocker sin un TPM compatible",
consulte la Referencia de la directiva de grupo de BitLocker.
La directiva de BitLocker en máquinas virtuales de unión a un dominio con directivas de grupo personalizadas
debe incluir la siguiente configuración: Configuración de almacenamiento de usuario de información de
recuperación de BitLocker -> Permitir clave de recuperación de 256 bits. Azure Disk Encryption presentará un
error cuando la configuración de la directiva de grupo personalizada para BitLocker sea incompatible. En
máquinas que no tengan la configuración de directiva correcta, puede que sea necesario aplicar la nueva
directiva, forzar la nueva directiva a actualizarse (gpupdate.exe /force) y luego reiniciar.
Azure Disk Encryption producirá un error si la directiva de grupo de nivel de dominio bloquea el algoritmo AES -
CBC, que BitLocker usa.
Requisitos de almacenamiento de la clave de cifrado

Azure Disk Encryption requiere Azure Key Vault para controlar y administrar las claves y los secretos de cifrado
de discos. El almacén de claves y las VM deben residir en la misma región y suscripción de Azure.
Para obtener más información, consulte Creación y configuración de un almacén de claves para Azure Disk
Encryption.
Terminología
En la siguiente tabla se definen algunos de los términos comunes que se usan en la documentación de cifrado de
disco de Azure:
TERMINOLOGÍA DEFINICIÓN
Azure Key Vault Key Vault es un servicio de administración de claves

criptográficas basado en módulos de seguridad de hardware
validados por el Estándar federal de procesamiento de
información (FIPS). Estos estándares ayudan a proteger las
claves criptográficas y los secretos confidenciales. Para
obtener más información, consulte la documentación de
Azure Key Vault y Creación y configuración de un almacén de
claves para Azure Disk Encryption.
CLI de Azure La CLI de Azure está optimizada para administrar recursos de

Azure desde la línea de comandos.
BitLocker BitLocker es una tecnología de cifrado de volúmenes de

Windows reconocida por el sector que se usa para habilitar el
cifrado de disco en VM Windows.
Clave de cifrado de claves (KEK) La clave asimétrica (RSA 2048) que puede usar para proteger
o encapsular el secreto. Puede proporcionar una clave
protegida mediante módulos de seguridad de hardware
(HSM) o una clave protegida mediante software. Para
obtener más información, consulte la documentación de
Azure Key Vault y Creación y configuración de un almacén de
claves para Azure Disk Encryption.
Cmdlets de PowerShell Para más información, consulte Cmdlets de Azure

PowerShell.
Pasos siguientes
Inicio rápido: Creación y cifrado de una máquina virtual Windows con la CLI de Azure
Inicio rápido: Creación y cifrado de una máquina virtual Windows con Azure Powershell
Escenarios de Azure Disk Encryption en máquinas virtuales Windows
Script de la CLI de requisitos previos de Azure Disk Encryption
Script de PowerShell de requisitos previos de Azure Disk Encryption
Creación y configuración de un almacén de claves para Azure Disk Encryption
Controles de seguridad para Windows Virtual
Machines
En este artículo, se documentan los controles de seguridad integrados en Windows Virtual Machines.
Un control de seguridad es una cualidad o característica de un servicio de Azure que ayuda a dicho servicio a
prevenir y detectar vulnerabilidades de seguridad, así como a responder a ellas.
En cada control, utilizamos "Sí" o "No" para indicar si este control está en vigor o no en el servicio, y "N/D" en el
caso de los controles que no están disponibles para el servicio. También se puede incluir una nota o un vínculo para
aportar más información sobre un atributo.
Red
CONTROL DE SEGURIDAD SÍ/NO NOTAS
Compatibilidad con el punto de Sí

conexión de servicio
Compatibilidad con la inserción de redes Sí

virtuales
Compatibilidad con el aislamiento de Sí

red y los firewalls
Compatibilidad con la tunelización Sí Consulte Configuración de la

forzada tunelización forzada mediante el modelo
de implementación de Azure Resource
Manager.
Supervisión y registro
Compatibilidad con la supervisión de Sí Supervisión y actualización de una

Azure (Log Analytics, Application máquina virtual Windows en Azure.
Insights, etc.)
Registro y auditoría del plano de Sí

administración y de control
Registro y auditoría del plano de datos Sin
Identidad
Authentication Sí
Authorization Sí
Protección de datos
Cifrado del lado servidor en reposo: Sí Consulte Cifrado de discos virtuales en

Claves administradas por Microsoft una máquina virtual con Windows.
Cifrado en tránsito (por ejemplo, cifrado Sí Azure Virtual Machines admite

de ExpressRoute, cifrado en la red ExpressRoute y el cifrado de red virtual.
virtual y cifrado de red virtual a red Consulte Cifrado en tránsito en
virtual) máquinas virtuales.
Cifrado del lado servidor en reposo: Sí Las claves administradas por el cliente
claves administradas por el cliente es un escenario de cifrado admitidos de
(BYOK) Azure; consulte Introducción al cifrado
de Azure.
Cifrado de nivel de columna (Azure Data N/D

Services)
Llamadas a API cifradas Sí A través de HTTPS y SSL.
Administración de configuración
Compatibilidad con la administración de Sí

configuración (control de versiones de
configuración, etc.)
Pasos siguientes
Más información sobre los controles de seguridad integrados en los servicios de Azure.
Estados y ciclo de vida de las máquinas virtuales
Las máquinas virtuales de Azure pueden tener diferentes estados que se pueden clasificar en estados de
aprovisionamiento y estados de energía. El propósito de este artículo es describir estos estados y resaltar
específicamente cuándo se les factura a los clientes por el uso de la instancia.
Estados de energía
El estado de energía representa el último estado conocido de la máquina virtual.
La tabla siguiente proporciona una descripción del estado de cada instancia e indica si se factura por uso de instancia o
no.
ESTADO DESCRIPCIÓN FACTURACIÓN DEL USO DE INSTANCIA
Starting (iniciándose) La máquina virtual se está iniciando. No facturado

"statuses": [
{
"code": "PowerState/starting",
"level": "Info",
"displayStatus": "VM starting"
}
]
Ejecución Estado de funcionamiento normal Facturado

para una máquina virtual
"statuses": [
{
"code": "PowerState/running",
"level": "Info",
"displayStatus": "VM running"
}
]
Stopping (Deteniéndose) Se trata de un estado transitorio. Facturado
Cuando haya terminado, aparecerá
como **Detenido**.
"statuses": [
{
"code": "PowerState/stopping",
"level": "Info",
"displayStatus": "VM stopping"
}
]
Stopped Se ha apagado la máquina virtual Facturado*

desde dentro del sistema operativo
invitado o está utilizando las API de
PowerOff.
El hardware aún está asignado a la
máquina virtual y permanece en el
host.
"statuses": [
{
"code": "PowerState/stopped",
"level": "Info",
"displayStatus": "VM stopped"
}
]
Desasignando Estado transitorio. Cuando haya No facturado*

terminado, la máquina virtual
aparecerá como **Desasignado**.
"statuses": [
{
"code":
"PowerState/deallocating",
"level": "Info",
"displayStatus": "VM
deallocating"
}
]
Desasignado La máquina virtual se ha detenido No facturado

correctamente y se ha eliminado del
host.
"statuses": [
{
"code": "PowerState/deallocated",
"level": "Info",
"displayStatus": "VM deallocated"
}
]
*Algunos recursos de Azure como los discos y las redes, incurren en gastos. Las licencias de software en la
instancia no cuestan nada.
Estados de aprovisionamiento
Un estado de aprovisionamiento es el estado de una operación de plano de control iniciada por el usuario en la
máquina virtual. Estos estados son independientes del estado de energía de una máquina virtual.
Crear: creación de máquinas virtuales.
Actualizar: actualiza el modelo de una máquina virtual existente. Algunos cambios no relacionados con el
modelo que se realizan en las máquinas virtuales, como Iniciar o Reiniciar, también se encuadran bajo la
opción Actualizar.
Eliminar: eliminación de máquinas virtuales.
Desasignar: es donde se detiene una máquina virtual y se elimina del host. Desasignar una máquina virtual
se considera una actualización, por lo que mostrará los estados de aprovisionamiento relacionados con la
actualización.
Estos son los estados de operación transitorios una vez que la plataforma ha aceptado una acción iniciada por el
usuario:
Estados DESCRIPCIÓN
Creando "statuses": [
{
"code": "ProvisioningState/creating",
"level": "Info",
"displayStatus": "Creating"
}
Actualizando "statuses": [
{
"code": "ProvisioningState/updating",
"level": "Info",
"displayStatus": "Updating"
}
]
Eliminando "statuses": [
{
"code": "ProvisioningState/deleting",
"level": "Info",
"displayStatus": "Deleting"
}
]
Estados de Si se crea una máquina virtual con una imagen de sistema operativo y no con una
aprovisionamiento del imagen especializada, se pueden observar los subestados siguientes:
sistema operativo
1. OSProvisioningInprogress – se está ejecutando la máquina virtual y la
instalación del sistema operativo invitado está en curso.
"statuses": [
{
"code": "ProvisioningState/creating/OSProvisioningInprogress",
"level": "Info",
"displayStatus": "OS Provisioning In progress"
}
]
2. OSProvisioningComplete – estado de corta duración. La máquina virtual pasa

rápidamente a **Correcto** a menos que haya que instalar alguna extensión. La
instalación de extensiones puede tardar un tiempo.
"statuses": [
{
"code": "ProvisioningState/creating/OSProvisioningComplete",
"level": "Info",
"displayStatus": "OS Provisioning Complete"
}
]
Nota: El aprovisionamiento del sistema operativo puede pasar a **Erróneo** si se

produce un error del sistema operativo o este no realiza la instalación a tiempo. A
los clientes se les facturará por la máquina virtual implementada en la
infraestructura.
Una vez completada la operación, la máquina virtual pasará a uno de los siguientes estados:
Correcto: se han completado las acciones iniciadas por el usuario.
"statuses": [
{
"code": "ProvisioningState/succeeded",
"level": "Info",
"displayStatus": "Provisioning succeeded",
"time": "time"
}
]
Erróneo: representa una operación con errores. Consulte los códigos de error para obtener más
información y posibles soluciones.
"statuses": [
{
"code": "ProvisioningState/failed/InternalOperationError",
"level": "Error",
"displayStatus": "Provisioning failed",
"message": "Operation abandoned due to internal error. Please try again later.",
"time": "time"
}
]
Vista de instancia de máquina virtual

La API de vista de instancia proporciona información sobre el estado de ejecución de la máquina virtual. Para más
información, consulte la documentación de API de Máquinas virtuales: Instance View.
Azure Resource Explorer proporciona una interfaz de usuario sencilla para ver el estado de ejecución de una
máquina virtual: Explorador de recursos.
Los estados de aprovisionamiento son visibles en las propiedades y la vista de instancia de la máquina virtual. Los
estados de energía están disponibles en la vista de instancia de la máquina virtual.
Pasos siguientes
Para obtener más información sobre la supervisión de la máquina virtual, consulte Supervisión de máquinas
virtuales en Azure.
Supervisión de máquinas virtuales en Azure
Con el crecimiento significativo de las máquinas virtuales hospedadas en Azure, es importante identificar los
problemas de rendimiento y de estado que afectan a las aplicaciones y los servicios de infraestructura que
admiten. Azure incluye supervisión básica de forma predeterminada, con las métricas de uso de CPU, uso de
disco, uso de memoria y tráfico de red que el hipervisor del host recopila. Se pueden recopilar datos de métricas y
de registro adicionales con extensiones para configurar el diagnóstico en las máquinas virtuales desde el sistema
operativo invitado.
Para detectar y ayudar a diagnosticar problemas de rendimiento y mantenimiento del sistema operativo invitado,
los componentes de aplicación web de Java o basados en .NET que se ejecutan dentro de la máquina virtual,
Azure Monitor ofrece supervisión centralizada con características completas como Azure Monitor para VM y
Application Insights.
Diagnósticos y métricas
Puede configurar y supervisar la recopilación de datos de diagnóstico con métricas en Azure Portal, la CLI de
Azure, Azure PowerShell y la programación de Interfaces de programación de aplicaciones (API). Por ejemplo,
puede:
Observar métricas básicas para la máquina virtual. En la pantalla Información general de Azure Portal,
entre las métricas básicas que se muestran se incluye el uso de CPU, el uso de la red, el total de bytes de
disco y las operaciones de disco por segundo.
Habilitar y observar la recopilación de diagnósticos de arranque y a través de Azure Portal.
Cuando lleva su propia imagen a Azure o incluso cuando arranca una de las imágenes de la plataforma,
puede haber muchas razones por las que una máquina virtual pueda entrar en un estado que no permita el
arranque. Puede habilitar fácilmente el diagnóstico de arranque cuando se crea una máquina virtual,
haciendo clic en Habilitado en Diagnóstico de arranque, en la sección Supervisión de la pantalla
Configuración.
Cuando las máquinas virtuales arrancan, el agente de los diagnósticos de arranque captura la salida del
arranque y la almacena en Azure Storage. Estos datos se pueden utilizar para solucionar los problemas de
arranque de la máquina virtual. Los diagnósticos de arranque no se habilitan automáticamente al crear una
máquina virtual mediante las herramientas de línea de comandos. Antes de habilitar los diagnósticos de
arranque, es preciso crear una cuenta de almacenamiento para almacenar los registros de arranque. Si
habilita el diagnóstico de arranque en Azure Portal, se crea automáticamente una cuenta de
almacenamiento.
Si no habilitó el diagnóstico de arranque cuando se creó la máquina virtual, siempre puede habilitarlo más
adelante con la CLI de Azure, Azure PowerShell o una plantilla de Azure Resource Manager.
Habilitar la recopilación de datos de diagnóstico del sistema operativo invitado. Cuando se crea
una máquina virtual, en la pantalla de configuración tiene la oportunidad de habilitar los diagnósticos del
sistema operativo invitado. Cuando habilita la recopilación de datos de diagnóstico, la extensión
IaaSDiagnostics para Linux o la extensión IaaSDiagnostics para Windows se agregan a la máquina virtual,
lo que le permite recopilar más datos de disco, CPU y memoria.
Con los datos de diagnóstico recopilados, puede configurar el escalado automático para las máquinas
virtuales. También puede configurar registros de Azure Monitor para almacenar los datos y configurar
alertas para informarle cuando el rendimiento no sea correcto.
Alertas
Puede crear alertas basadas en métricas de rendimiento concretas. Algunos problemas de los que se puede alertar
son, por ejemplo, cuando el uso promedio de la CPU supera un umbral concreto o cuando el espacio libre en disco
disponible cae por debajo de una cantidad determinada. Es posible configurar alertas en Azure Portal, con
plantillas de Azure Resource Manager o la CLI de Azure.
Azure Service Health

Azure Service Health proporciona soporte técnico e información orientativa personalizada cuando se producen
problemas en los servicios de Azure que le afectan, y le ayuda a prepararse para los próximos mantenimientos
planeados. Azure Service Health le informa de las alertas a usted y a los equipos por medio de notificaciones
específicas y flexibles.
Azure Resource Health

Azure Resource health ayuda a diagnosticar si un problema de Azure afecta a los recursos y, en su caso, a obtener
soporte técnico. Le informa acerca del mantenimiento actual y pasado de los recursos y le ayuda a mitigar los
problemas. Resource Health le proporciona soporte técnico si necesita ayuda con los problemas de los servicios
de Azure.
Azure Activity Log

Azure Activity Log es un registro de suscripción que proporciona información sobre los eventos de nivel de
suscripción que se han producido en Azure. Este registro incluye una serie de datos, desde datos operativos de
Azure Resource Manager hasta actualizaciones en eventos de Service Health. Puede hacer clic en Activity Log, en
Azure Portal, para ver el registro de la máquina virtual.
Estas son algunas de las tareas que puede hacer con el registro de actividad:
Crear una alerta basada en un evento de Activity Log.
Transmitirlo a un centro de eventos para la ingesta en un servicio de terceros o una solución de análisis
personalizado como Power BI.
Analizarlo en Power BI con el paquete de contenido de Power BI.
Guardarlo en una cuenta de almacenamientopara archivarlo o inspeccionarlo manualmente. Puede especificar
el tiempo de retención (en días) mediante el perfil de registro.
También puede tener acceso a datos de registro de actividad mediante Azure PowerShell, la CLI de Azure o las API
de REST de Monitor.
Los registros de recursos de Azure son registros emitidos por una máquina virtual que proporcionan datos
exhaustivos y frecuentes acerca de su funcionamiento. Los registros de recursos se diferencian del registro de
actividad en que proporcionan una visión general acerca de las operaciones realizadas dentro de la máquina
virtual.
Estas son algunas de las cosas que puede hacer con los registros de diagnóstico:
Guardarlos en una cuenta de almacenamiento para auditarlos o para inspeccionarlos manualmente. Puede
especificar el tiempo de retención (en días) mediante Configuración de diagnóstico de recursos.
Transmitirlos a Event Hubs para la ingesta en un servicio de terceros o una solución de análisis personalizado
como Power BI.
Analizarlos con Log Analytics.
Supervisión avanzada
Habilite tanto Azure Monitor para VM como Application Insights para dar visibilidad a la aplicación o el servicio
que la máquina virtual de Azure y los conjuntos de escalado de máquinas virtuales admiten e identificar los
problemas del sistema operativo invitado o de la carga de trabajo que se ejecuta en la máquina virtual para
comprender si está afectando a la disponibilidad o el rendimiento de la aplicación o si es un problema de la
aplicación.
La solución Azure Monitor para VM supervisa las máquinas virtuales de Azure a escala al analizar el rendimiento
y el estado de las máquinas virtuales Windows y Linux, incluidos los diferentes procesos y las dependencias
interconectadas con otros recursos y con los procesos externos que detecta. Incluye varios gráficos de rendimiento
de las tendencias para ayudarle en la investigación de problemas y evaluar la capacidad de las máquinas virtuales.
El mapa de dependencias muestra las máquinas supervisadas y no supervisadas, las conexiones de red con
errores y las conexiones activas entre los procesos y estas máquinas. También muestra gráficos de tendencias con
métricas de conexión de red estándar. En combinación con Application Insights, puede supervisar la aplicación y
capturar datos de telemetría, tales como solicitudes HTTP o excepciones, para que pueda correlacionar los
problemas entre las máquinas virtuales y la aplicación. Configure las alertas de Azure Monitor para recibir alertas
sobre las condiciones importantes detectadas durante la supervisión de los datos recopilados por Azure Monitor
para VM.
Pasos siguientes
Siga los pasos de Supervisión de una máquina virtual Windows con Azure PowerShell o de Supervisión de
una máquina Virtual Linux con la CLI de Azure.
Más información sobre las prácticas recomendadas de la supervisión y el diagnóstico.
Opciones de copia de seguridad y restauración de
máquinas virtuales en Azure
Para proteger sus datos realice copias de seguridad a intervalos regulares. Hay varias opciones de copia de
seguridad disponibles para máquinas virtuales, según el caso de uso.
Azure Backup
Para realizar copias de seguridad de máquinas virtuales de Azure que ejecutan cargas de trabajo de producción,
use Azure Backup. Azure Backup admite las copias de seguridad coherentes con la aplicación para máquinas
virtuales Windows y Linux. Azure Backup crea puntos de recuperación que se almacenan en almacenes de
recuperación con redundancia geográfica. Cuando se realiza una restauración desde un punto de recuperación, se
puede restaurar toda una máquina virtual o solo determinados archivos.
Para obtener una introducción simple y práctica sobre Azure Backup para máquinas virtuales de Azure, consulte el
tutorial "Copia de seguridad de máquinas virtuales de Azure" para Linux o Windows.
Para más información sobre cómo funciona Azure Backup, consulte Planeamiento de la infraestructura de copia de
seguridad de máquinas virtuales en Azure
Azure Site Recovery

Azure Site Recovery permite proteger las máquinas virtuales en un escenario grave de desastre en el que toda una
región experimenta una interrupción debido a un desastre natural importante o a una interrupción del servicio
generalizada. Puede configurar Azure Site Recovery para las VM de modo que pueda recuperar la aplicación con
un solo clic en cuestión de minutos. Puede realizar replicaciones en la región de Azure que elija, no solo en
regiones emparejadas.
Puede ejecutar maniobras de recuperación ante desastres con conmutaciones por error de prueba a petición, sin
que las cargas de trabajo de producción o la replicación en curso se vean afectadas. Cree planes de recuperación
para orquestar la conmutación por error y la conmutación por recuperación de toda la aplicación que se ejecuta en
varias máquinas virtuales. La característica de los planes de recuperación está integrada con runbooks de Azure
Automation.
Puede empezar por replicar las máquinas virtuales.
Instantáneas administradas
En entornos de desarrollo y prueba, las instantáneas proporcionan una opción rápida y sencilla para realizar copias
de seguridad de máquinas virtuales que usan Managed Disks. Una instantánea administrada es una copia
completa de solo lectura de un disco administrado. Las instantáneas existen independientemente del disco de
origen y se pueden usar para recompilar una máquina virtual. Se facturan según la porción usada del disco. Por
ejemplo, si crea una instantánea de un disco administrado con capacidad aprovisionada de 64 GB y el tamaño de
datos usado real es de 10 GB, solo se le cobrará por el tamaño de datos usado de 10 GB.
Para más información sobre la creación de instantáneas, consulte:
Creación de una copia del disco duro virtual que se almacene como un disco administrado mediante
instantáneas en Windows
Creación de una copia del disco duro virtual que se almacene como un disco administrado mediante
instantáneas en Linux
Pasos siguientes
Puede probar Azure Backup siguiendo el tutorial "Copia de seguridad de máquinas virtuales Windows" para Linux
o Windows.
Tutorial de la infraestructura de Azure de ejemplo
Este artículo le guía a través de la creación de una infraestructura de aplicación de ejemplo. Detallaremos el diseño
de una infraestructura para una tienda en línea sencilla que reúna todas las directrices y decisiones relacionadas
con las convenciones de nomenclatura, los conjuntos de disponibilidad, las redes virtuales, los equilibradores de
carga y, de hecho, la implementación de sus máquinas virtuales (VM ).
Carga de trabajo de ejemplo

Adventure Works Cycles quiere compilar una aplicación de tienda en línea en Azure que conste de lo siguiente:
Dos servidores IIS que ejecuten el front-end de cliente en un nivel web
Dos servidores IIS que procesen datos y pedidos en un nivel de aplicación
Dos instancias de Microsoft SQL Server con grupos de disponibilidad AlwaysOn (dos servidores SQL Server y
un testigo de mayoría de nodo) para almacenar datos de productos y pedidos en un nivel de base de datos
Dos controladores de dominio de Active Directory para los proveedores y las cuentas de cliente en un nivel de
autenticación
Todos los servidores se encuentran en dos subredes:
una subred front-end para los servidores web
una subred back-end para los servidores de aplicaciones, un clúster de SQL y controladores de dominio
El tráfico web seguro entrante debe ser de carga equilibrada entre los servidores web a medida que los clientes
examinan la tienda en línea. El tráfico de procesamiento de pedidos en forma de solicitudes HTTP procedente de
los servidores web debe equilibrarse entre los servidores de aplicaciones. Además, la infraestructura debe
diseñarse para alta disponibilidad.
El diseño resultante incluirá:
Una suscripción y una cuenta de Azure
Un único grupo de recursos
Azure Managed Disks
Una red virtual con dos subredes
Conjuntos de disponibilidad para las máquinas virtuales con un rol similar
Máquinas virtuales
Todo lo anterior seguirá estas convenciones de nomenclatura:
Adventure Works Cycles usa [carga de trabajo de TI ]-[ubicación]-[recurso de Azure] como prefijo
En este ejemplo, "azos" (siglas en inglés de "tienda en línea de Azure") es el nombre de la carga de
trabajo de TI y "use" (siglas en inglés de "este de EE. UU. 2") es la ubicación.
Las redes virtuales usan AZOS -USE -VN [número]
Los conjuntos de disponibilidad usan azos-use-as- [rol]
Los nombres de máquinas virtuales usan azos-use-vm- [vmname]
Suscripciones y cuentas de Azure

Adventure Works Cycles usa la suscripción Enterprise, denominada Adventure Works Enterprise Subscription,
para proporcionar la facturación de esta carga de trabajo de TI.
Storage
Adventure Works Cycles determina que deben usar Azure Managed Disks. Al crear VM, se utilizan ambos niveles
de almacenamiento disponibles:
Almacenamiento estándar de los servidores web, los servidores de aplicaciones y los controladores de
dominio y sus discos de datos.
Premium Storage de máquinas virtuales de SQL Server y sus discos de datos.

Dado que la red virtual no necesita una conectividad continua con la red local de Adventure Work Cycles, la
empresa optó por una red virtual solo en la nube.
Creó una red virtual solo en la nube con la siguiente configuración a través del Portal de Azure:
Nombre: AZOS -USE -VN01
Ubicación: Este de EE. UU. 2
Espacio de direcciones de red virtual: 10.0.0.0/8
Primera subred:
Nombre: FrontEnd
Espacio de direcciones: 10.0.1.0/24
Segunda subred:
Nombre: BackEnd
Espacio de direcciones: 10.0.2.0/24
Para mantener la alta disponibilidad de los cuatro niveles de su tienda en línea, Adventure Works Cycles optó por
cuatro conjuntos de disponibilidad:
azos-use-as-web para los servidores web
azos-use-as-app para los servidores de aplicaciones
azos-use-as-sql para los servidores SQL Server
azos-use-as-dc para los controladores de dominio
Máquinas virtuales
Adventure Works Cycles decidió los siguientes nombres para sus máquinas virtuales de Azure:
azos-use-vm -web01 para el primer servidor web
azos-use-vm -web02 para el segundo servidor web
azos-use-vm -app01 para el primer servidor de aplicaciones
azos-use-vm -app02 para el segundo servidor de aplicaciones
azos-use-vm -sql01 para el primer servidor SQL Server del clúster
azos-use-vm -sql02 para el segundo servidor SQL Server del clúster
azos-use-vm -dc01 para el primer controlador de dominio
azos-use-vm -dc02 para el segundo controlador de dominio
Aquí está la configuración resultante.
Esta configuración incluye:

Una red virtual solo en la nube con dos subredes (FrontEnd y BackEnd)
Azure Managed Disks con discos Standard y Premium
Cuatro conjuntos de disponibilidad, uno para cada nivel de la tienda en línea
Las máquinas virtuales para los cuatro niveles
Un conjunto externo de carga equilibrada para el tráfico web basado en HTTPS de Internet a los servidores
web
Un conjunto interno de carga equilibrada para el tráfico web sin cifrar de los servidores web a los servidores de
aplicaciones
Un único grupo de recursos
Vista previa: Implementación de máquinas virtuales
en hosts dedicados mediante Azure PowerShell
En este artículo se ofrecen instrucciones para crear un host dedicado de Azure en el que se pueden hospedar
máquinas virtuales (VM ).
Asegúrese de que tiene instalada la versión 2.4.2 de Azure PowerShell, o cualquier versión posterior, y que inicia
sesión en una cuenta de Azure con Connect-AzAccount . Para instalar la versión 2.4.2, abra un símbolo del sistema
de PowerShell y escriba:
Install-Module -Name Az.Compute -Repository PSGallery -RequiredVersion 2.4.2-preview -AllowPrerelease
necesitará al menos la versión 1.6.0 del módulo PowerShellGet para habilitar la funcionalidad del módulo de vista
previa en PowerShell. Las versiones más recientes de PowerShell Core lo integran automáticamente, pero en las
versiones anteriores de PowerShell, puede ejecutar el siguiente comando para realizar la actualización a la versión
más reciente:
Install-Module -Name PowerShellGet -Repository PSGallery -Force
IMPORTANT
Azure Dedicated Host está actualmente en versión preliminar pública. Esta versión preliminar se ofrece sin Acuerdo de Nivel
de Servicio y no se recomienda para cargas de trabajo de producción. Es posible que algunas características no sean
Creación de un grupo host

Un grupo host es un recurso que representa una colección de hosts dedicados. Puede crear un grupo host en
una región y una zona de disponibilidad, y agregarle hosts. Al planear la alta disponibilidad, hay otras opciones.
Puede usar una o ambas de las dos opciones siguientes con los hosts dedicados:
Abarcar varias zonas de disponibilidad. En este caso, es necesario tener un grupo host en cada una de las
zonas que quiera usar.
Abarcar varios dominios de error que se asignan a bastidores físicos.
En cualquier caso, es necesario proporcionar el número de dominios de error del grupo host. Si no quiere abarcar
dominios de error en el grupo, use un número de dominios de error de 1.
También puede usar zonas de disponibilidad y dominios de error a la vez. En este ejemplo se crea en la zona 1 un
grupo host con dos dominios de error.
$rgName = "myDHResourceGroup"
New-AzResourceGroup -Location $location -Name $rgName

$hostGroup = New-AzHostGroup `
-Name myHostGroup `
-PlatformFaultDomain 2 `
-Zone 1
Creación de un host
Ahora vamos a crear un host dedicado en el grupo host. Además de un nombre para el host, se le pedirá que
proporcione el SKU del host. El SKU del host registra la serie de máquinas virtuales admitidas, así como la
generación de hardware del host dedicado. Durante la versión preliminar, se admitirán los siguientes valores de
SKU de host: DSv3_Type1 y ESv3_Type1.
Para más información sobre los precios y los SKU de host, consulte Precios de hosts dedicados de Azure.
Si establece un número de dominios de error para el grupo host, se le pedirá que especifique el dominio de error
para su host. En este ejemplo, se establece el dominio de error para el host en 1.
$dHost = New-AzHost `
-HostGroupName $hostGroup.Name `
-Location $location -Name myHost `
-Sku DSv3-Type1 `
-AutoReplaceOnFailure 1 `
-PlatformFaultDomain 1
Crear una VM
Cree una máquina virtual en el host dedicado.
Si especificó una zona de disponibilidad al crear el grupo host, debe usar la misma zona al crear la máquina
virtual. En este ejemplo, como el grupo host está en la zona 1, es preciso crear la máquina virtual en la zona 1.
New-AzVM `
-Credential $cred `
-Name myVM `
-HostId $dhost.Id `
-Image Win2016Datacenter `
-Zone 1 `
-Size Standard_D4s_v3
WARNING
Si crea una máquina virtual en un host que no tenga suficientes recursos, la máquina virtual se creará en un estado de error.
Comprobación del estado del host

Mediante el uso de GetAzHost con el parámetro -InstanceView puede comprobar el estado de mantenimiento del
host y el número de máquinas virtuales que aún se pueden implementar.
Get-AzHost `
-Name myHost `
-HostGroupName $hostGroup.Name `
-InstanceView
El resultado será similar al siguiente:

ResourceGroupName : myDHResourceGroup
PlatformFaultDomain : 1
AutoReplaceOnFailure : True
HostId : 12345678-1234-1234-abcd-abc123456789
ProvisioningTime : 7/28/2019 5:31:01 PM
ProvisioningState : Succeeded
InstanceView :
AssetId : abc45678-abcd-1234-abcd-123456789abc
AvailableCapacity :
AllocatableVMs[0] :
VmSize : Standard_D2s_v3
Count : 32
AllocatableVMs[1] :
Count : 16
AllocatableVMs[2] :
Count : 8
AllocatableVMs[3] :
Count : 4
AllocatableVMs[4] :
VmSize : Standard_D32-8s_v3
Count : 2
AllocatableVMs[5] :
Count : 2
AllocatableVMs[6] :
Count : 2
AllocatableVMs[7] :
Count : 1
AllocatableVMs[8] :
Count : 1
AllocatableVMs[9] :
Count : 1
Statuses[0] :
Code : ProvisioningState/succeeded
Level : Info
DisplayStatus : Provisioning succeeded
Time : 7/28/2019 5:31:01 PM
Statuses[1] :
Code : HealthState/available
Level : Info
DisplayStatus : Host available
Sku :
Name : DSv3-Type1
Id : /subscriptions/10101010-1010-1010-1010-101010101010/re
sourceGroups/myDHResourceGroup/providers/Microsoft.Compute/hostGroups/myHostGroup/hosts
/myHost
Name : myHost
Location : eastus
Tags : {}
Limpieza
Aunque no se implementen máquinas virtuales, se le cobrará por los hosts dedicados. Elimine los hosts que no
use actualmente para ahorrar costos.
Solo se puede eliminar un host cuando no haya ninguna máquina virtual que lo use. Elimine las máquinas
virtuales mediante el comandoRemove-AzVM.
Remove-AzVM -ResourceGroupName $rgName -Name myVM
Después de eliminar las máquinas virtuales, puede eliminar el host mediante Remove-AzHost.
Remove-AzHost -ResourceGroupName $rgName -Name myHost
Una vez que haya eliminado todos los hosts, puede eliminar el grupo host medianteRemove-AzHostGroup.
Remove-AzHost -ResourceGroupName $rgName -Name myHost
También puede eliminar todo el grupo de recursos con un solo comando mediante Remove-AzResourceGroup.
Se eliminarán todos los recursos creados en el grupo, lo que incluye las máquinas virtuales, los hosts y los grupos
host.
Remove-AzResourceGroup -Name $rgName
Pasos siguientes
En este vínculo encontrará una plantilla de ejemplo en la que se usan zonas y dominios de error para
obtener la máxima resistencia en una región.
También se pueden implementar hosts dedicados desde Azure Portal.
Vista previa: implementación de máquinas virtuales
en hosts dedicados mediante el portal
En este artículo se ofrecen instrucciones para crear un host dedicado de Azure en el que se pueden hospedar
máquinas virtuales (VM ).
IMPORTANT
Los hosts dedicados de Azure están actualmente en versión preliminar pública. Esta versión preliminar se ofrece sin Acuerdo
de Nivel de Servicio y no se recomienda para cargas de trabajo de producción. Es posible que algunas características no
sean compatibles o que tengan sus funcionalidades limitadas. Para más información, consulte Términos de uso
complementarios de las Versiones Preliminares de Microsoft Azure.
Creación de un grupo host

Un grupo host es un nuevo recurso que representa una colección de hosts dedicados. Puede crear un grupo host
en una región y una zona de disponibilidad, y agregarle hosts. Al planear la alta disponibilidad, hay otras
opciones. Puede usar una o ambas de las dos opciones siguientes con los hosts dedicados:
Abarcar varias zonas de disponibilidad. En este caso, es necesario tener un grupo host en cada una de las
zonas que quiera usar.
Abarcar varios dominios de error que se asignan a bastidores físicos.
En cualquier caso, es necesario proporcionar el número de dominios de error del grupo host. Si no quiere abarcar
dominios de error en el grupo, use un número de dominios de error de 1.
También puede usar zonas de disponibilidad y dominios de error a la vez.
En este ejemplo, se creará un grupo host con una zona de disponibilidad y dos dominios de error.
1. Abra el portal.
2. Seleccione Crear un recurso en la esquina superior izquierda.
3. Busque el grupo host y, a continuación, seleccione los grupos host (versión preliminar) en los
resultados.
4. En la página de los grupos host (versión preliminar) , seleccione Crear.
5. Seleccione la suscripción que quiere usar y, a continuación, seleccione Crear nuevo para crear un nuevo
grupo de recursos.
6. Escriba myDedicatedHostsRG como nombre y seleccione Aceptar.
7. En el nombre del grupo host, escriba myHostGroup.
8. En Ubicación, seleccione Este de EE.UU.
9. Para la zona de disponibilidad, seleccione 1.
10. En el recuento de dominios de error, seleccione 2.
11. Seleccione Revisar y crear y, a continuación, espere a la confirmación.
12. Cuando reciba el mensaje de Validación superada, seleccione Crear para crear el grupo host.
Solo tardará unos minutos en crear el grupo host.
Creación de un host dedicado
Ahora crearemos un host dedicado en el grupo host. Además de un nombre para el host, se le pedirá que
proporcione el SKU del host. El SKU del host registra la serie de máquinas virtuales admitidas, así como la
generación de hardware del host dedicado. Durante la versión preliminar, se admitirán los siguientes valores de
SKU de host: DSv3_Type1 y ESv3_Type1.
Para más información sobre los precios y los SKU de host, consulte Precios de hosts dedicados de Azure.
Si establece un número de dominios de error para el grupo host, se le pedirá que especifique el dominio de error
para su host.
1. Seleccione Crear un recurso en la esquina superior izquierda.
2. Busque un host dedicado y, a continuación, seleccione los hosts dedicados (versión preliminar) en los
resultados.
3. En la página de hosts dedicados ( versión preliminar) , seleccione Crear.

4. Seleccione la suscripción que quiere usar.
5. Seleccione myDedicatedHostsRG como grupo de recursos.
6. En los detalles de la instancia, escriba myHost en el nombre y seleccione Este de EE. UU. como
ubicación.
7. En el perfil de hardware, seleccione familia Es3 estándar: tipo 1 para la familia de tamaños, seleccione
myHostGrup en el grupo host y, a continuación, seleccione 1 en el dominio de error. En el resto de los
campos, deje los valores predeterminados.
8. Cuando termine, seleccione Revisar y crear y, a continuación, espere a la confirmación.
9. Cuando reciba el mensaje de Validación superada, seleccione Crear para crear el host.
Crear una VM
1. Elija Crear un recurso en la esquina superior izquierda de Azure Portal.
2. En la página Nuevo, en Popular, seleccione Windows Server 2016 Datacenter.
3. En la pestaña Aspectos básicos, en Detalles del proyecto, asegúrese de que esté seleccionada la
suscripción correcta y, a continuación, seleccione myDedicatedHostsRG como grupo de recursos.
4. En Detalles de instancia, escriba myVM en Nombre de máquina virtual y elija Este de EE. UU. como
Ubicación.
5. En Opciones de disponibilidad, seleccione Zona de disponibilidad y seleccione 1 en la lista desplegable.
6. En cuanto al tamaño, seleccione Cambiar tamaño. En la lista de tamaños disponibles, elija uno de la serie
Esv3, como Standard E2s v3. Es posible que tenga que borrar el filtro para ver todos los tamaños disponibles.
7. En Cuenta de administrador, proporcione un nombre de usuario, como azureuser, y una contraseña. La
contraseña debe tener al menos 12 caracteres de largo y cumplir con los requisitos de complejidad definidos.
8. En Reglas de puerto de entrada, elija Permitir los puertos seleccionados y luego seleccione RDP (3389)
en la lista desplegable.
9. En la parte superior de la página, seleccione la pestaña Opciones avanzadas y, en la sección Host, seleccione
myHostGroup para el grupo host y myHost para el host.
10. Deje los valores predeterminados restantes y luego seleccione el botón Revisar + crear en la parte inferior de
la página.
11. Cuando vea que la validación del mensaje se ha superado, seleccione Crear.
Pasos siguientes
Para obtener más información, consulte la introducción Hosts dedicados.
En este vínculo encontrará una plantilla de ejemplo en la que se usan zonas y dominios de error para
obtener la máxima resistencia en una región.
Asimismo, puede implementar un host dedicado mediante Azure PowerShell.
Creación y administración de máquinas virtuales
Windows en Azure mediante C#
Las máquinas virtuales de Azure necesitan varios recursos de Azure compatibles. En este artículo se trata la
creación, la administración y la eliminación de recursos de máquina virtual con C#. Aprenderá a:
Creación de un proyecto de Visual Studio
Instalación del paquete
Crear credenciales
Crear recursos
Realizar tareas de administración
Eliminar recursos
Ejecución de la aplicación
Tardará unos 20 minutos en realizar estos pasos.

1. Si aún no lo ha hecho, instale Visual Studio. Seleccione Desarrollo de escritorio de .NET en la página Cargas
de trabajo y haga clic en Instalar. En el resumen, puede ver que Herramientas de desarrollo de .NET
Framework 4 – 4.6 se selecciona automáticamente. Si ya ha instalado Visual Studio, puede agregar la carga de
trabajo de .NET con el selector de Visual Studio.
2. En Visual Studio, haga clic en Archivo > Nuevo > proyecto.
3. En Plantillas > Visual C# , seleccione Aplicación de consola (.NET Framework) , escriba myDotnetProject
como nombre del proyecto, seleccione la ubicación del proyecto y, haga clic en Aceptar.
Instalación del paquete

Los paquetes de NuGet son la manera más fácil de instalar las bibliotecas que necesita para finalizar estos pasos.
Para obtener las bibliotecas que necesita en Visual Studio, siga estos pasos:
1. Haga clic en Herramientas > Administrador de paquetes Nuget y, después, haga clic en Consola del
Administrador de paquetes.
2. Escriba el siguiente comando en la consola:
Install-Package Microsoft.Azure.Management.Fluent
Crear credenciales
Antes de empezar este paso, asegúrese de que tiene acceso a una entidad de servicio de Active Directory. También
debe registrar el identificador de aplicación, la clave de autenticación y el identificador del inquilino que necesitará
en un paso posterior.
Creación del archivo de autorización
1. En el Explorador de soluciones, haga clic en myDotnetProject > Agregar > Nuevo elemento y, después,
seleccione Archivo de texto en Elementos de Visual C# . Asigne un nombre al archivo
azureauth.properties y, luego, haga clic en Agregar.
2. Agregue estas propiedades de autorización:
subscription=<subscription-id>
client=<application-id>
key=<authentication-key>
tenant=<tenant-id>
managementURI=https://management.core.windows.net/
baseURL=https://management.azure.com/
authURL=https://login.windows.net/
graphURL=https://graph.windows.net/
Reemplace <subscription-id> por su identificador de suscripción, <application-id> por el identificador

de aplicación de Active Directory, <authentication-key> por la clave de aplicación y <tenant-id> por el
identificador de inquilino.
3. Guarde el archivo azureauth.properties.
4. Establezca una variable de entorno de Windows denominada AZURE_AUTH_LOCATION con la ruta de
acceso completa al archivo de autorización que ha creado. Por ejemplo, puede usar el comando de
PowerShell siguiente:
[Environment]::SetEnvironmentVariable("AZURE_AUTH_LOCATION", "C:\Visual Studio

2019\Projects\myDotnetProject\myDotnetProject\azureauth.properties", "User")
Creación del cliente de administración

1. Abra el archivo Program.cs del proyecto que ha creado. A continuación, agregue estas instrucciones using a
las instrucciones existentes en la parte superior del archivo:
using Microsoft.Azure.Management.Compute.Fluent;
using Microsoft.Azure.Management.Compute.Fluent.Models;
using Microsoft.Azure.Management.Fluent;
using Microsoft.Azure.Management.ResourceManager.Fluent;
using Microsoft.Azure.Management.ResourceManager.Fluent.Core;
2. Para crear el cliente de administración, agregue este código al método Main:
var credentials = SdkContext.AzureCredentialsFactory

.FromFile(Environment.GetEnvironmentVariable("AZURE_AUTH_LOCATION"));
var azure = Azure

.Configure()
.WithLogLevel(HttpLoggingDelegatingHandler.Level.Basic)
.Authenticate(credentials)
.WithDefaultSubscription();
Crear recursos
Creación del grupo de recursos
Todos los recursos deben encontrarse en un grupo de recursos.
Para especificar los valores de la aplicación y crear el grupo de recursos, agregue este código al método Main:
var groupName = "myResourceGroup";
var vmName = "myVM";
var location = Region.USWest;
Console.WriteLine("Creating resource group...");

var resourceGroup = azure.ResourceGroups.Define(groupName)
.WithRegion(location)
.Create();
Creación del conjunto de disponibilidad

Los conjuntos de disponibilidad facilitan el mantenimiento de las máquinas virtuales que utiliza la aplicación.
Para crear el conjunto de disponibilidad, agregue este código al método Main:
Console.WriteLine("Creating availability set...");

var availabilitySet = azure.AvailabilitySets.Define("myAVSet")
.WithExistingResourceGroup(groupName)
.WithSku(AvailabilitySetSkuTypes.Managed)
.Create();
Crear la dirección IP pública

Se necesita una dirección IP pública para la comunicación con la máquina virtual.
Para crear la dirección IP pública de la máquina virtual, agregue este código al método Main:
Console.WriteLine("Creating public IP address...");

var publicIPAddress = azure.PublicIPAddresses.Define("myPublicIP")
.WithDynamicIP()
.Create();
Crear la red virtual

Debe haber una máquina virtual en una subred de una red virtual.
Para crear una subred y una red virtual, agregue este código al método Main:
Console.WriteLine("Creating virtual network...");

var network = azure.Networks.Define("myVNet")
.WithAddressSpace("10.0.0.0/16")
.WithSubnet("mySubnet", "10.0.0.0/24")
.Create();
Creación de la interfaz de red

Una máquina virtual requiere una interfaz de red para comunicarse en la red virtual que acaba de crear.
Para crear una interfaz de red, agregue este código al método Main:
Console.WriteLine("Creating network interface...");
var networkInterface = azure.NetworkInterfaces.Define("myNIC")
.WithExistingPrimaryNetwork(network)
.WithSubnet("mySubnet")
.WithPrimaryPrivateIPAddressDynamic()
.WithExistingPrimaryPublicIPAddress(publicIPAddress)
.Create();
Creación de la máquina virtual

Ahora que ha creado todos los recursos auxiliares, puede crear una máquina virtual.
Para crear la máquina virtual, agregue este código al método Main:
Console.WriteLine("Creating virtual machine...");

azure.VirtualMachines.Define(vmName)
.WithExistingPrimaryNetworkInterface(networkInterface)
.WithLatestWindowsImage("MicrosoftWindowsServer", "WindowsServer", "2012-R2-Datacenter")
.WithAdminUsername("azureuser")
.WithAdminPassword("Azure12345678")
.WithComputerName(vmName)
.WithExistingAvailabilitySet(availabilitySet)
.WithSize(VirtualMachineSizeTypes.StandardDS1)
.Create();
NOTE
En este tutorial se crea una máquina virtual donde se ejecuta una versión del sistema operativo Windows Server. Para más
información sobre cómo seleccionar otras imágenes, consulte Seleccione y navegue por imágenes de máquina virtual de
Azure con PowerShell y la CLI de Azure.
Si desea usar un disco existente en lugar de una imagen de Marketplace, use este código:
var managedDisk = azure.Disks.Define("myosdisk")

.WithWindowsFromVhd("https://mystorage.blob.core.windows.net/vhds/myosdisk.vhd")
.WithSizeInGB(128)
.WithSku(DiskSkuTypes.PremiumLRS)
.Create();
azure.VirtualMachines.Define("myVM")
.WithExistingPrimaryNetworkInterface(networkInterface)
.WithSpecializedOSDisk(managedDisk, OperatingSystemTypes.Windows)
.WithExistingAvailabilitySet(availabilitySet)
.Create();

Durante el ciclo de vida de una máquina virtual, puede ejecutar tareas de administración como iniciar, detener o
eliminar una máquina virtual. Además, puede crear código para automatizar tareas repetitivas o complejas.
Cuando tenga que hacerlas con la máquina virtual, deberá obtener una instancia de ella:
var vm = azure.VirtualMachines.GetByResourceGroup(groupName, vmName);
Obtención de información acerca de la máquina virtual

Para obtener información acerca de la máquina virtual, agregue este código al método Main:
Console.WriteLine("Getting information about the virtual machine...");
Console.WriteLine("hardwareProfile");
Console.WriteLine(" vmSize: " + vm.Size);
Console.WriteLine("storageProfile");
Console.WriteLine(" imageReference");
Console.WriteLine(" publisher: " + vm.StorageProfile.ImageReference.Publisher);
Console.WriteLine(" offer: " + vm.StorageProfile.ImageReference.Offer);
Console.WriteLine(" sku: " + vm.StorageProfile.ImageReference.Sku);
Console.WriteLine(" version: " + vm.StorageProfile.ImageReference.Version);
Console.WriteLine(" osDisk");
Console.WriteLine(" osType: " + vm.StorageProfile.OsDisk.OsType);
Console.WriteLine(" name: " + vm.StorageProfile.OsDisk.Name);
Console.WriteLine(" createOption: " + vm.StorageProfile.OsDisk.CreateOption);
Console.WriteLine(" caching: " + vm.StorageProfile.OsDisk.Caching);
Console.WriteLine("osProfile");
Console.WriteLine(" computerName: " + vm.OSProfile.ComputerName);
Console.WriteLine(" adminUsername: " + vm.OSProfile.AdminUsername);
Console.WriteLine(" provisionVMAgent: " + vm.OSProfile.WindowsConfiguration.ProvisionVMAgent.Value);
Console.WriteLine(" enableAutomaticUpdates: " +
vm.OSProfile.WindowsConfiguration.EnableAutomaticUpdates.Value);
Console.WriteLine("networkProfile");
foreach (string nicId in vm.NetworkInterfaceIds)
{
Console.WriteLine(" networkInterface id: " + nicId);
}
Console.WriteLine("vmAgent");
Console.WriteLine(" vmAgentVersion" + vm.InstanceView.VmAgent.VmAgentVersion);
Console.WriteLine(" statuses");
foreach (InstanceViewStatus stat in vm.InstanceView.VmAgent.Statuses)
{
Console.WriteLine(" code: " + stat.Code);
Console.WriteLine(" level: " + stat.Level);
Console.WriteLine(" displayStatus: " + stat.DisplayStatus);
Console.WriteLine(" message: " + stat.Message);
Console.WriteLine(" time: " + stat.Time);
}
Console.WriteLine("disks");
foreach (DiskInstanceView disk in vm.InstanceView.Disks)
{
Console.WriteLine(" name: " + disk.Name);
Console.WriteLine(" statuses");
foreach (InstanceViewStatus stat in disk.Statuses)
{
Console.WriteLine(" time: " + stat.Time);
}
}
Console.WriteLine("VM general status");
Console.WriteLine(" provisioningStatus: " + vm.ProvisioningState);
Console.WriteLine(" id: " + vm.Id);
Console.WriteLine(" name: " + vm.Name);
Console.WriteLine(" type: " + vm.Type);
Console.WriteLine(" location: " + vm.Region);
Console.WriteLine("VM instance status");
foreach (InstanceViewStatus stat in vm.InstanceView.Statuses)
{
}
Console.WriteLine("Press enter to continue...");
Console.ReadLine();
Parada de la máquina virtual

Puede detener una máquina virtual y mantener toda su configuración, pero se le seguirá cobrando, o puede
detener una máquina virtual y desasignarla. Cuando se desasigna una máquina virtual, todos los recursos
asociados a ella también se desasignan y se le deja de cobrar por ellos.
Para detener la máquina virtual sin desasignarla, agregue este código al método Main:
Console.WriteLine("Stopping vm...");
vm.PowerOff();
Console.ReadLine();
Si desea desasignar la máquina virtual, cambie la llamada de PowerOff por este código:
vm.Deallocate();
Inicio de la máquina virtual

Para iniciar la máquina virtual, agregue este código al método Main:
Console.WriteLine("Starting vm...");
vm.Start();
Console.ReadLine();
Cambio de tamaño de la máquina virtual

Para decidir un tamaño de máquina virtual, se deben considerar muchos aspectos de la implementación. Para más
información, consulte el artículo sobre los tamaños de máquina virtual.
Para cambiar el tamaño de la máquina virtual, agregue este código al método Main:
Console.WriteLine("Resizing vm...");
vm.Update()
.Apply();
Console.ReadLine();
Incorporación de un disco de datos a la máquina virtual

Para agregar un disco de datos a la máquina virtual, agregue este código al método Main. Este ejemplo agrega un
disco de datos de 2 GB de tamaño, con un LUN de 0 y un tipo de almacenamiento en caché de lectura y escritura:
Console.WriteLine("Adding data disk to vm...");

vm.Update()
.WithNewDataDisk(2, 0, CachingTypes.ReadWrite)
.Apply();
Console.WriteLine("Press enter to delete resources...");
Console.ReadLine();
Eliminar recursos
Dado que se le cobrará por los recursos utilizados en Azure, siempre es conveniente eliminar los recursos que ya
no sean necesarios. Si quiere eliminar las máquinas virtuales y todos los recursos auxiliares, lo único que tiene que
hacer es eliminar el grupo de recursos.
Para eliminar el grupo de recursos, agregue este código al método Main:
azure.ResourceGroups.DeleteByName(groupName);
Esta aplicación de consola tardará unos cinco minutos en ejecutarse completamente de principio a fin.
1. Para ejecutar la aplicación de consola, haga clic en Iniciar.
2. Antes de presionar Entrar para comenzar la eliminación de recursos, puede dedicar unos minutos a
comprobar la creación de los recursos en Azure Portal. Haga clic en el estado de implementación para ver
información de la implementación.
Pasos siguientes
Aproveche las ventajas de usar una plantilla para crear una máquina virtual con la información que se muestra
en Implementación de una máquina virtual de Azure con C# y una plantilla de Resource Manager.
Para más información acerca del uso de las bibliotecas de Azure para .NET.
Creación de una máquina virtual a partir de un VHD
mediante Azure Portal
Hay varias maneras de crear una máquina virtual en Azure:

Si ya tiene un disco duro virtual (VHD ) que puede usar o quiere copiar el VHD de una máquina virtual
existente para usarlo, puede crear una nueva máquina virtual adjuntando el VHD a la nueva máquina
virtual como disco del sistema operativo.
Puede crear una nueva máquina virtual desde el VHD de una máquina virtual que haya sido eliminada. Por
ejemplo, si tiene una máquina virtual de Azure que no funciona correctamente, puede eliminarla y usar su
VHD para crear una nueva. Puede volver a usar el mismo VHD o crear una copia del VHD mediante la
creación de una instantánea y, a continuación, de un nuevo disco administrado desde la instantánea.
Aunque la creación de una instantánea conlleva unos pocos pasos más, conserva el VHD original y le
proporcionará una reserva.
Tome una máquina virtual clásica y use el disco duro virtual para crear una VM nueva que use los discos
administrados y el modelo de implementación de Resource Manager. Para obtener los mejores resultados,
detenga la máquina virtual clásica en Azure Portal antes de crear la instantánea.
Puede crear una máquina virtual de Azure desde un VHD local mediante la carga del VHD local y su
conexión a una nueva máquina virtual. Puede utilizar PowerShell u otra herramienta para cargar el VHD a
una cuenta de almacenamiento y, a continuación, crear un disco administrado a partir del VHD. Para más
información, consulte Carga de un VHD especializado.
No use un disco especializado si desea crear varias máquinas virtuales. En su lugar, para implementaciones más
grandes, debe crear una imagen y, a continuación, usarla para crear varias máquinas virtuales.
Se recomienda limitar el número de implementaciones simultáneas desde una sola instantánea o VHD a
20 máquinas virtuales.
Copiar un disco
Cree una instantánea y, a continuación, cree un disco a partir de la instantánea. Esta estrategia le permite
conservar el VHD original como reserva:
1. En Azure Portal, seleccione Todos los servicios en el menú de la izquierda.
2. En el cuadro de búsqueda Todos los servicios, escriba discos y, a continuación, seleccione discos para
mostrar la lista de discos disponibles.
3. Seleccione el disco que le gustaría utilizar. Aparece la página Disco de ese disco.
4. En el menú de la parte superior, seleccione Crear instantánea.
5. Escriba un nombre para la instantánea.
6. Elija un Grupo de recursos para la instantánea. Puede usar un grupo de recursos existente o crear uno nuevo.
7. En Tipo de cuenta, elija almacenamiento Estándar (HDD ) o Premium (SSD ) .
8. Cuando haya terminado, seleccione Crear para crear la instantánea.
9. Una vez creada la instantánea, seleccione Crear un recurso en el menú izquierdo.
10. En el cuadro de búsqueda, escriba disco administrado y seleccione Discos administrados en la lista.
11. En la página Discos administrados, seleccione Crear.
12. Escriba un Nombre para el disco.
13. Elija un Grupo de recursos para el disco. Puede usar un grupo de recursos existente o crear uno nuevo. Esta
selección también se usará como el grupo de recursos donde crear la máquina virtual desde el disco.
14. En Tipo de cuenta, elija almacenamiento Estándar (HDD ) o Premium (SSD ) .
15. En Tipo de origen, asegúrese de que está seleccionada la opción Instantánea.
16. En el desplegable Instantánea de origen, seleccione la instantánea que quiere usar.
17. Realice cualquier otro ajuste que sea necesario y, a continuación, seleccione Crear para crear el disco.
Creación de una VM desde un disco

Una vez que tenga el VHD del disco administrado que quiere usar, puede crear la máquina virtual en el portal:
1. En Azure Portal, seleccione Todos los servicios en el menú de la izquierda.
2. En el cuadro de búsqueda Todos los servicios, escriba discos y, a continuación, seleccione discos para
mostrar la lista de discos disponibles.
3. Seleccione el disco que le gustaría utilizar. Se abre la página Disco de ese disco.
4. En la página Información general, asegúrese de que ESTADO DEL DISCO aparezca como Sin adjuntar. Si
no es el caso, es posible que tenga que desasociar el disco de la VM o eliminar la VM para liberar el disco.
5. En el menú de la parte superior de la página, seleccione Crear máquina virtual.
6. En la página Aspectos básicos de la nueva máquina virtual, escriba un Nombre de máquina virtual y
seleccione un Grupo de recursos existente o cree uno nuevo.
7. En Tamaño, seleccione Cambiar tamaño para acceder a la página Tamaño.
8. Seleccione una fila de tamaño de máquina virtual y, a continuación, elija Seleccionar.
9. En la página Redes, puede dejar que el portal cree todos los recursos nuevos o puede seleccionar una Red
virtual y un Grupo de seguridad de red existentes. El portal crea siempre una nueva interfaz de red y una
dirección IP pública para la nueva máquina virtual.
10. En la página Administración, realice los cambios oportunos en las opciones de supervisión.
11. En la página Configuración de invitado, agregue extensiones según sea necesario.
12. Seleccione Revisar y crear cuando haya terminado.
13. Si la configuración de la máquina virtual supera la validación, seleccione Crear para iniciar la implementación.
Pasos siguientes
También puede usar PowerShell para cargar un VHD en Azure y crear una VM especializada.
Creación de una VM de Windows desde un disco
especializado mediante PowerShell
Cree una nueva VM asociando un disco administrado especializado como disco del SO. Un disco especializado es
una copia del disco duro virtual (VHD ) de una máquina virtual existente que contiene las cuentas de usuario, las
aplicaciones y otros datos de estado de la máquina virtual original.
Cuando se usa un VHD especializado para crear una máquina virtual, la nueva máquina virtual conserva el
nombre de equipo de la máquina virtual original. También se conserva otra información específica del equipo y,
en algunos casos, esta información duplicada podría ocasionar problemas. Al copiar una máquina virtual, tenga en
cuenta en qué tipo de información específica del equipo se basan las aplicaciones.
Tiene varias opciones:
Uso de un disco administrado existente. Esta opción es útil si tiene una VM que no funciona correctamente.
Puede eliminar la máquina virtual y, después, reutilizar el disco administrado para crear una nueva.
Carga de un disco duro virtual
Copia de una VM de Azure existente mediante instantáneas
También puede usar Azure Portal para crear una nueva VM a partir de un VHD especializado.
En este artículo se muestra cómo usar los discos administrados. Si tiene una implementación heredada que
requiere el uso de una cuenta de almacenamiento, vea Create a VM from a specialized VHD in a storage account
(Creación de una máquina virtual a partir de un VHD especializado en una cuenta de almacenamiento).
Se recomienda limitar el número de implementaciones simultáneas a 20 máquinas virtuales desde una sola
instantánea o VHD.
Opción 1: Uso de un disco existente

Si tenía una VM que ha eliminado y quiere volver a usar el disco del sistema operativo para crear una nueva VM,
use Get-AzDisk.
$resourceGroupName = 'myResourceGroup'
$osDiskName = 'myOsDisk'
$osDisk = Get-AzDisk `
-ResourceGroupName $resourceGroupName `
-DiskName $osDiskName
Ahora puede adjuntar este disco como disco del sistema operativo a una nueva VM.
Opción 2: Carga de un disco duro virtual especializado

Puede cargar el VHD de una máquina virtual especializada creada con una herramienta de virtualización local,
como Hyper-V, o de una máquina virtual exportada desde otra nube.
Use el disco duro virtual tal cual para crear una nueva máquina virtual.
Preparar de un VHD de Windows para cargar en Azure. No generalice la VM mediante Sysprep.
Quite todas las herramientas de virtualización de invitado y los agentes instalados en la VM (como las
herramientas de VMware).
Asegúrese de que la VM se configura para obtener la dirección IP y la configuración de DNS desde DHCP.
Esto garantiza que el servidor obtiene una dirección IP dentro de la red virtual cuando se inicia.
Carga del disco duro virtual
Ahora puede cargar un disco duro virtual directamente en un disco administrado. Para obtener instrucciones al
respecto, consulte Carga de un disco duro virtual en Azure mediante Azure PowerShell.
Opción 3: Copia de una máquina virtual de Azure existente

Puede crear una copia de una máquina virtual que use discos administrados mediante la realización de una
instantánea de la máquina virtual, para usarla después para crear un disco administrado y una máquina virtual.
Si quiere copiar una máquina virtual existente en otra región, quizá quiera usar azcopy para crear una copia de un
disco en otra región.
Realización de la instantánea del disco del SO
Puede realizar una instantánea de una máquina virtual completa (incluidos todos los discos) o solo de un disco. En
los pasos siguientes se describe cómo hacer una instantánea solo del disco del SO de la VM con el cmdlet New -
AzSnapshot.
Primero, configure algunos parámetros.
$vmName = 'myVM'
$snapshotName = 'mySnapshot'
Obtenga el objeto de VM.
$vm = Get-AzVM -Name $vmName `

-ResourceGroupName $resourceGroupName
Obtenga el nombre del disco del SO.
$disk = Get-AzDisk -ResourceGroupName $resourceGroupName `

-DiskName $vm.StorageProfile.OsDisk.Name
Cree la configuración de la instantánea.
$snapshotConfig = New-AzSnapshotConfig `
-SourceUri $disk.Id `
-OsType Windows `
-CreateOption Copy `
-Location $location
Tome la instantánea.
$snapShot = New-AzSnapshot `
-Snapshot $snapshotConfig `
-SnapshotName $snapshotName `
Para usar esta instantánea para crear una VM que precisa de un alto rendimiento, agregue el parámetro
-AccountType Premium_LRS al comando New -AzSnapshotConfig. Este parámetro crea la instantánea para que se
almacene como disco administrado Prémium. Los discos administrados Prémium son más caros que los Estándar,
así que asegúrese de que necesita Prémium antes de usar este parámetro.
Creación de un disco a partir de la instantánea
Cree un disco administrado a partir de la instantánea mediante New -AzDisk. Este ejemplo usa myOSDisk para el
nombre del disco.
Cree un grupo de recursos para la máquina virtual.
$destinationResourceGroup = 'myDestinationResourceGroup'
New-AzResourceGroup -Location $location `
-Name $destinationResourceGroup
Defina el nombre del disco del SO.
$osDiskName = 'myOsDisk'
Cree el disco administrado.
$osDisk = New-AzDisk -DiskName $osDiskName -Disk `

(New-AzDiskConfig -Location $location -CreateOption Copy `
-SourceResourceId $snapshot.Id) `
-ResourceGroupName $destinationResourceGroup

Cree recursos de red y otros recursos de máquina virtual para que los use la nueva máquina virtual.
Creación de la subred y de la red virtual
Cree la red virtual y la subred para la máquina virtual.
1. Cree la subred. En este ejemplo se crea una subred llamada mySubNet, en el grupo de recursos
myDestinationResourceGroup y se establece el prefijo de la dirección de subred en 10.0.0.0/24.
$subnetName = 'mySubNet'
$singleSubnet = New-AzVirtualNetworkSubnetConfig `
-Name $subnetName `
2. Creación de la red virtual. En este ejemplo se establece el nombre de la red virtual en myVnetName, la
ubicación en Oeste de EE. UU. y el prefijo de dirección de la red virtual en 10.0.0.0/16.
$vnetName = "myVnetName"
-Name $vnetName -ResourceGroupName $destinationResourceGroup `
-Subnet $singleSubnet
Creación del grupo de seguridad de red y las reglas de RDP

Para poder iniciar sesión en la máquina virtual con el protocolo de escritorio remoto (RDP ), debe tener una regla
de seguridad que permita el acceso RDP en el puerto 3389. En nuestro ejemplo, el disco duro virtual de la nueva
máquina virtual se creó a partir de una máquina virtual especializada existente, por lo que puede usar una cuenta
de la máquina virtual de origen para RDP.
En este ejemplo se establece el nombre del grupo de seguridad de red (NSG ) en myNsg y el nombre de la regla
de RDP en myRdpRule.
$nsgName = "myNsg"
$rdpRule = New-AzNetworkSecurityRuleConfig -Name myRdpRule -Description "Allow RDP" `

$nsg = New-AzNetworkSecurityGroup `
-ResourceGroupName $destinationResourceGroup `
-Name $nsgName -SecurityRules $rdpRule
Para obtener más información sobre puntos de conexión y las reglas NSG, consulte Apertura de puertos para una
máquina virtual en Azure mediante PowerShell.
Creación de una dirección IP pública y una NIC
Para permitir la comunicación con la máquina virtual en la red virtual, necesitará una dirección IP pública y una
interfaz de red.
1. Cree la dirección IP pública. En este ejemplo, el nombre de la dirección IP pública se establece en myIP.
$ipName = "myIP"
$pip = New-AzPublicIpAddress `
-Name $ipName -ResourceGroupName $destinationResourceGroup `
2. Cree la NIC. En este ejemplo, el nombre de la NIC se establece en myNicName.
$nicName = "myNicName"
$nic = New-AzNetworkInterface -Name $nicName `
-ResourceGroupName $destinationResourceGroup `
-Location $location -SubnetId $vnet.Subnets[0].Id `
-PublicIpAddressId $pip.Id `
-NetworkSecurityGroupId $nsg.Id
Establecimiento del nombre de VM y el tamaño

En este ejemplo se establece el nombre de la máquina virtual como myVM y el tamaño de la máquina virtual en
Standard_A2.
$vmName = "myVM"
$vmConfig = New-AzVMConfig -VMName $vmName -VMSize "Standard_A2"
Incorporación de la NIC
$vm = Add-AzVMNetworkInterface -VM $vmConfig -Id $nic.Id
Adición del disco del SO

Agregue el disco del SO a la configuración mediante Set-AzVMOSDisk. Este ejemplo establece el tamaño del
disco en 128 GB y adjunta el disco administrado como un disco del SO Windows.
$vm = Set-AzVMOSDisk -VM $vm -ManagedDiskId $osDisk.Id -StorageAccountType Standard_LRS `

-DiskSizeInGB 128 -CreateOption Attach -Windows
Finalización de la máquina virtual

Cree la VM mediante New -AzVM con las configuraciones que se acaban de crear.
New-AzVM -ResourceGroupName $destinationResourceGroup -Location $location -VM $vm
Si este comando es correcto, verá un resultado similar al siguiente:
RequestId IsSuccessStatusCode StatusCode ReasonPhrase

--------- ------------------- ---------- ------------
True OK OK
Comprobación de que se creó la máquina virtual

Debería ver la máquina virtual recién creada en el Azure Portal, en Examinar > Máquinas virtuales o mediante
los comandos de PowerShell siguientes.
$vmList = Get-AzVM -ResourceGroupName $destinationResourceGroup

$vmList.Name
Pasos siguientes
Inicie sesión en la nueva máquina virtual. Para más información, consulte Conexión a una máquina virtual de
Azure donde se ejecuta Windows Server e inicio de sesión en ella.
Implementación de una máquina virtual de Azure
con C# y una plantilla de Resource Manager
En este artículo se muestra cómo implementar una plantilla de Azure Resource Manager con C#. La plantilla que
crea implementa una sola máquina virtual que ejecuta Windows Server en una nueva red virtual con una sola
subred.
Para obtener una descripción detallada del recurso de máquina virtual, consulte Virtual machines in an Azure
Resource Manager template (Máquinas virtuales en una plantilla de Azure Resource Manager). Para obtener más
información acerca de todos los recursos de una plantilla, consulte Tutorial de la plantilla de Resource Manager.

En este paso, asegúrese de que está instalado Visual Studio y cree una aplicación de consola que se utilice para
implementar la plantilla.
1. Si aún no lo ha hecho, instale Visual Studio. Seleccione Desarrollo de escritorio de .NET en la página Cargas
de trabajo y haga clic en Instalar. En el resumen, puede ver que Herramientas de desarrollo de .NET
Framework 4 – 4.6 se selecciona automáticamente. Si ya ha instalado Visual Studio, puede agregar la carga de
trabajo de .NET con el selector de Visual Studio.
2. En Visual Studio, haga clic en Archivo > Nuevo > proyecto.
3. En Plantillas > Visual C# , seleccione Aplicación de consola (.NET Framework) , escriba myDotnetProject
como nombre del proyecto, seleccione la ubicación del proyecto y, haga clic en Aceptar.
Instalación de los paquetes

Los paquetes de NuGet son la manera más fácil de instalar las bibliotecas que necesita para finalizar estos pasos.
Para obtener las bibliotecas que necesita en Visual Studio, siga estos pasos:
1. Haga clic en Herramientas > Administrador de paquetes Nuget y, después, haga clic en Consola del
Administrador de paquetes.
2. En la consola, escriba estos comandos:
Install-Package Microsoft.Azure.Management.Fluent
Install-Package WindowsAzure.Storage
Creación de los archivos

En este paso, creará un archivo de plantilla que implementa los recursos y un archivo de parámetros que
proporciona valores de parámetro a la plantilla. También creará un archivo de autorización que se utiliza para
realizar operaciones de Azure Resource Manager.
Cree el archivo de plantilla
CreateVMTemplate.json y, después, haga clic en Agregar.
2. Agregue este código JSON al archivo creado:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"adminUsername": { "type": "string" },
"adminPassword": { "type": "securestring" }
},
"variables": {
"vnetID": "[resourceId('Microsoft.Network/virtualNetworks','myVNet')]",
"subnetRef": "[concat(variables('vnetID'),'/subnets/mySubnet')]",
},
"resources": [
{
"apiVersion": "2016-03-30",
"type": "Microsoft.Network/publicIPAddresses",
"name": "myPublicIPAddress",
"location": "[resourceGroup().location]",
"properties": {
"publicIPAllocationMethod": "Dynamic",
"dnsSettings": {
"domainNameLabel": "myresourcegroupdns1"
}
}
},
{
"apiVersion": "2016-03-30",
"type": "Microsoft.Network/virtualNetworks",
"name": "myVNet",
"properties": {
"addressSpace": { "addressPrefixes": [ "10.0.0.0/16" ] },
"subnets": [
{
"name": "mySubnet",
"properties": { "addressPrefix": "10.0.0.0/24" }
}
]
}
},
{
"apiVersion": "2016-03-30",
"type": "Microsoft.Network/networkInterfaces",
"name": "myNic",
"dependsOn": [
"[resourceId('Microsoft.Network/publicIPAddresses/', 'myPublicIPAddress')]",
"[resourceId('Microsoft.Network/virtualNetworks/', 'myVNet')]"
],
"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"privateIPAllocationMethod": "Dynamic",
"publicIPAddress": { "id": "
[resourceId('Microsoft.Network/publicIPAddresses','myPublicIPAddress')]" },
"subnet": { "id": "[variables('subnetRef')]" }
}
}
]
}
},
{
"apiVersion": "2016-04-30-preview",
"name": "myVM",
"name": "myVM",
"dependsOn": [
"[resourceId('Microsoft.Network/networkInterfaces/', 'myNic')]"
],
"properties": {
"hardwareProfile": { "vmSize": "Standard_DS1" },
"osProfile": {
"computerName": "myVM",
"adminUsername": "[parameters('adminUsername')]",
"adminPassword": "[parameters('adminPassword')]"
},
"storageProfile": {
"imageReference": {
"sku": "2012-R2-Datacenter",
"version": "latest"
},
"osDisk": {
"name": "myManagedOSDisk",
"caching": "ReadWrite",
}
},
"networkProfile": {
"networkInterfaces": [
{
"id": "[resourceId('Microsoft.Network/networkInterfaces','myNic')]"
}
]
}
}
}
]
}
3. Guarde el archivo CreateVMTemplate.json.

Cree el archivo de parámetros
Para especificar los valores de los parámetros de recurso en la plantilla, debe crear un archivo de parámetros que
contenga los valores.
seleccione Archivo de texto en Elementos de Visual C# . Asigne un nombre al archivo Parameters.json y,
después, haga clic en Agregar.
2. Agregue este código JSON al archivo creado:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json",
"parameters": {
"adminUserName": { "value": "azureuser" },
"adminPassword": { "value": "Azure12345678" }
}
}
3. Guarde el archivo Parameters.json.

Antes de poder implementar una plantilla, asegúrese de que tiene acceso a una entidad de servicio de Active
Directory. Desde la entidad de servicio, adquiera un token para autenticar solicitudes a Azure Resource Manager.
También debe registrar el identificador de aplicación, la clave de autenticación y el identificador del inquilino que
necesitará en el archivo de autorización.
azureauth.properties y, luego, haga clic en Agregar.
2. Agregue estas propiedades de autorización:
tenant=<tenant-id>

3. Guarde el archivo azureauth.properties.
4. Establezca una variable de entorno de Windows llamada AZURE_AUTH_LOCATION con la ruta de acceso
completa al archivo de autorización que ha creado; por ejemplo, puede usar el siguiente comando de
PowerShell:
[Environment]::SetEnvironmentVariable("AZURE_AUTH_LOCATION", "C:\Visual Studio

2019\Projects\myDotnetProject\myDotnetProject\azureauth.properties", "User")

1. Abra el archivo Program.cs del proyecto que ha creado. A continuación, agregue estas instrucciones using a
las instrucciones existentes en la parte superior del archivo:
using Microsoft.Azure.Management.Compute.Fluent;
using Microsoft.Azure.Management.Compute.Fluent.Models;
using Microsoft.Azure.Management.Fluent;
using Microsoft.Azure.Management.ResourceManager.Fluent;
using Microsoft.Azure.Management.ResourceManager.Fluent.Core;
using Microsoft.WindowsAzure.Storage;
using Microsoft.WindowsAzure.Storage.Blob;
2. Para crear el cliente de administración, agregue este código al método Main:
var credentials = SdkContext.AzureCredentialsFactory

.FromFile(Environment.GetEnvironmentVariable("AZURE_AUTH_LOCATION"));
var azure = Azure

.Configure()
.WithLogLevel(HttpLoggingDelegatingHandler.Level.Basic)
.Authenticate(credentials)
.WithDefaultSubscription();

Con el fin de especificar valores para la aplicación, agregue el código al método Main:
var groupName = "myResourceGroup";

var location = Region.USWest;
var resourceGroup = azure.ResourceGroups.Define(groupName)

.Create();
Crear una cuenta de almacenamiento

La plantilla y los parámetros se implementan desde una cuenta de almacenamiento de Azure. En este paso, va a
crear la cuenta y cargar los archivos.
Para crear la cuenta, agregue este código al método Main:
string storageAccountName = SdkContext.RandomResourceName("st", 10);
Console.WriteLine("Creating storage account...");

var storage = azure.StorageAccounts.Define(storageAccountName)
.WithRegion(Region.USWest)
.WithExistingResourceGroup(resourceGroup)
.Create();
var storageKeys = storage.GetKeys();

string storageConnectionString = "DefaultEndpointsProtocol=https;"
+ "AccountName=" + storage.Name
+ ";AccountKey=" + storageKeys[0].Value
+ ";EndpointSuffix=core.windows.net";
var account = CloudStorageAccount.Parse(storageConnectionString);

var serviceClient = account.CreateCloudBlobClient();
Console.WriteLine("Creating container...");
var container = serviceClient.GetContainerReference("templates");
container.CreateIfNotExistsAsync().Wait();
var containerPermissions = new BlobContainerPermissions()
{ PublicAccess = BlobContainerPublicAccessType.Container };
container.SetPermissionsAsync(containerPermissions).Wait();
Console.WriteLine("Uploading template file...");

var templateblob = container.GetBlockBlobReference("CreateVMTemplate.json");
templateblob.UploadFromFileAsync("..\\..\\CreateVMTemplate.json").Result();
Console.WriteLine("Uploading parameters file...");

var paramblob = container.GetBlockBlobReference("Parameters.json");
paramblob.UploadFromFileAsync("..\\..\\Parameters.json").Result();
Implementación de la plantilla
Implemente la plantilla y los parámetros de la cuenta de almacenamiento que creó.
Para implementar la plantilla, agregue este código al método Main:
var templatePath = "https://" + storageAccountName + ".blob.core.windows.net/templates/CreateVMTemplate.json";
var paramPath = "https://" + storageAccountName + ".blob.core.windows.net/templates/Parameters.json";
var deployment = azure.Deployments.Define("myDeployment")
.WithTemplateLink(templatePath, "1.0.0.0")
.WithParametersLink(paramPath, "1.0.0.0")
.WithMode(Microsoft.Azure.Management.ResourceManager.Fluent.Models.DeploymentMode.Incremental)
.Create();
Console.WriteLine("Press enter to delete the resource group...");
Console.ReadLine();
Eliminación de los recursos

no sean necesarios. No es necesario eliminar por separado cada recurso de un grupo de recursos. Elimine el grupo
de recursos y todos sus recursos se eliminarán automáticamente.
Para eliminar el grupo de recursos, agregue este código al método Main:
azure.ResourceGroups.DeleteByName(groupName);
1. Para ejecutar la aplicación de consola, haga clic en Iniciar.
Pasos siguientes
Si se produjeron problemas durante la implementación, el paso siguiente sería consultar Solución de errores
comunes de implementación de Azure con Azure Resource Manager.
Obtenga información sobre cómo implementar una máquina virtual y los recursos de apoyo leyendo
Implementación de una máquina virtual de Azure con C#.
Automatización de la implementación de la máquina
virtual de Azure con Chef
Chef es una fantástica herramienta para ofrecer automatización y las configuraciones de estado que desee.
Con la versión de API de nube más reciente, Chef proporciona una perfecta integración con Azure, lo que ofrece la
posibilidad de aprovisionar e implementar los estados de configuración mediante un único comando.
En este artículo, se configura un entorno de Chef para aprovisionar máquinas virtuales de Azure y se le guía por la
creación de una directiva o "libro de recetas", y su posterior implementación en una máquina virtual de Azure.
Conceptos básicos de Chef

Antes de comenzar, revise los conceptos básicos de Chef.
El diagrama siguiente muestra la arquitectura Chef de alto nivel.
La arquitectura de Chef tiene tres componentes principales: el servidor Chef, el cliente Chef (nodo) y la estación de
trabajo Chef.
El servidor Chef es el punto de administración y hay dos opciones para el servidor Chef: una solución hospedada o
una solución local.
El cliente Chef (nodo) es el agente que se encuentra en los servidores que está administrando.
La estación de trabajo Chef es el nombre tanto de la estación de trabajo de administración en la que se crean
directivas y se ejecutan comandos de administración como del paquete de software de las herramientas de Chef.
Por lo general, verá su estación de trabajo como la ubicación en la que puede realizar acciones y la estación de
trabajo Chef como el paquete de software. Por ejemplo, el comando de knife se descargará como parte de la
estación de trabajo Chef, pero los comandos de knife que administran la infraestructura se ejecutan desde su
estación de trabajo.
Chef también usa los conceptos de "libros de recetas" y "recetas", que son realmente las directivas que definimos y
aplicamos a los servidores.
Preparación de la estación de trabajo

En primer lugar, prepare la estación de trabajo mediante la creación de un directorio que almacene archivos de
configuración de Chef y libros de recetas.
Cree un directorio denominado C:\Chef.
Descargue e instale la última versión de la CLI de Azure en su estación de trabajo.
Configuración de una entidad de servicio de Azure

Explicándolo de forma sencilla, una entidad de servicio de Azure es una cuenta de servicio. Usaremos una entidad
de servicio para ayudarnos a crear recursos de Azure desde nuestra estación de trabajo Chef. Para crear la entidad
de servicio correspondiente con los permisos necesarios, tenemos que ejecutar los siguientes comandos en
PowerShell:
Login-AzureRmAccount
Get-AzureRmSubscription
Select-AzureRmSubscription -SubscriptionName "<yourSubscriptionName>"
$myApplication = New-AzureRmADApplication -DisplayName "automation-app" -HomePage "https://chef-automation-
test.com" -IdentifierUris "https://chef-automation-test.com" -Password "#1234p$wdchef19"
New-AzureRmADServicePrincipal -ApplicationId $myApplication.ApplicationId
New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $myApplication.ApplicationId
Apunte los valores de SubscriptionID, TenantID, ClientID y el secreto de cliente (la contraseña que ha establecido
antes), los necesitará más adelante.
Configuración del servidor Chef

En esta guía se da por supuesto que se registrará para Hosted Chef.
Si no usa un servidor Chef, puede:
Registrarse para obtener Hosted Chef, que es la forma más rápida de empezar a usar Chef.
Instalar un servidor Chef independiente en el equipo con Linux siguiendo las instrucciones de instalación de
Chef Docs.
Creación de una cuenta de Hosted Chef
Para disfrutar de una cuenta de Hosted Chef, regístrese aquí.
Durante el proceso de registro, se le pedirá que cree una organización.
Cuando se cree la organización, descargue el starter kit.
NOTE
Si recibe un mensaje que le advierte que se restablecerán las claves, está bien continuar como si no tuviéramos ninguna
infraestructura existente configurada todavía.
El archivo zip de Starter Kit contiene los archivos de configuración y la clave de usuario de la organización que
están en el directorio .chef .
organization-validator.pem debe descargarse por separado, porque es una clave privada y las claves privadas no
se deben almacenar en el servidor Chef. En Chef Manage, vaya a la sección de administración y seleccione "Reset
Validation Key" (Restablecer clave de validación); se le proporcionará un archivo que se descarga por separado.
Guarde el archivo en c:\chef.
Configuración de la estación de trabajo Chef
Extraiga el contenido del archivo chef-starter.zip en c:\chef.
Copie todos los archivos de chef-starter\chef-repo.chef en el directorio c:\chef.
Copie el archivo organization-validator.pem en c:\chef, si se guarda en c:\Downloads
El directorio debería tener ahora un aspecto similar al siguiente ejemplo.
Directory: C:\Users\username\chef
Mode LastWriteTime Length Name

---- ------------- ------ ----
d----- 12/6/2018 6:41 PM .chef
d----- 12/6/2018 5:40 PM chef-repo
d----- 12/6/2018 5:38 PM cookbooks
d----- 12/6/2018 5:38 PM roles
-a---- 12/6/2018 5:38 PM 495 .gitignore
-a---- 12/6/2018 5:37 PM 1678 azuredocs-validator.pem
-a---- 12/6/2018 5:38 PM 1674 user.pem
-a---- 12/6/2018 5:53 PM 414 knife.rb
-a---- 12/6/2018 5:38 PM 2341 README.md
Ahora debería tener cinco archivos y cuatro directorios (incluido el directorio chef-repo vacío) en la raíz de c:\chef.
Edición de knife.rb
Los archivos PEM contienen sus claves privadas de organización y administración para la comunicación y el
archivo knife.rb contiene la configuración de knife. Tendremos que editar el archivo knife.rb.
Abra el archivo knife.rb en el editor que prefiera. El archivo sin modificar debe ser similar a este:
current_dir = File.dirname(__FILE__)
log_level :info
log_location STDOUT
node_name "mynode"
client_key "#{current_dir}/user.pem"
chef_server_url "https://api.chef.io/organizations/myorg"
cookbook_path ["#{current_dir}/cookbooks"]
Agregue la siguiente información a knife.rb:

validation_client_name "validador-de-la-organización"
validation_key "#{directorio_actual}/myorg.pem"
knife[:azure_tenant_id] = "0000000-1111-aaaa-bbbb-222222222222"
knife[:azure_subscription_id] = "11111111-bbbbb-cccc-1111-222222222222"
knife[:azure_client_id] = "11111111-bbbbb-cccc-1111-2222222222222"
knife[:azure_client_secret] = "#1234p$wdchef19"
Estas líneas asegurarán que Knife haga referencia al directorio de cookbooks en c:\chef\cookbooks y que también
use la entidad de servicio de Azure que ha creado durante las operaciones de Azure.
Ahora el archivo knife.rb debería ser ahora similar al del siguiente ejemplo:
log_level :info
log_location STDOUT
node_name "myorg"
client_key "#{current_dir}/myorg.pem"
validation_client_name "myorg-validator"
validation_key "#{current_dir}/myorg-validator.pem"
cookbook_path ["#{current_dir}/../cookbooks"]
Instalación de la estación de trabajo Chef

A continuación, descargue e instale la estación de trabajo Chef. Instale la estación de trabajo Chef en la ubicación
predeterminada. Esta instalación puede tardar unos minutos.
En el escritorio, verá "CW PowerShell", que es un entorno que se carga con la herramienta que se necesita para
interactuar con los productos de Chef. CW PowerShell permite usar nuevos comandos ad hoc, como chef-run , así
como comandos tradicionales de la CLI de Chef, como chef . Consulte la versión instalada de la estación de trabajo
Chef y de las herramientas de Chef con chef -v . También puede consultar la versión de la estación de trabajo. Para
ello, debe seleccionar "About Chef Workstation" (Acerca de la estación de trabajo Chef) en la aplicación de la
estación de trabajo Chef.
chef --version debe devolver algo similar a esto:
Chef Workstation: 0.4.2

chef-run: 0.3.0
chef-client: 15.0.300
delivery-cli: 0.0.52 (9d07501a3b347cc687c902319d23dc32dd5fa621)
berks: 7.0.8
test-kitchen: 2.2.5
inspec: 4.3.2
NOTE
El orden de la ruta de acceso es importante. Si las rutas de acceso de opscode no están en el orden correcto, tendrá
problemas.
Reinicie la estación de trabajo antes de continuar.

Instalación de Knife Azure
En este tutorial se da por supuesto que usa Azure Resource Manager para interactuar con su máquina virtual.
Instale la extensión de Knife Azure. De esta se proporciona a Knife el "complemento de Azure".
Ejecute el siguiente comando.
chef gem install knife-azure ––pre
NOTE
El argumento –pre garantiza que está recibiendo la versión de RC más reciente del complemento Knife Azure que ofrece
acceso al conjunto más reciente de API.
Es probable que también se instalen varias dependencias al mismo tiempo.
Para garantizar que todo esté configurado correctamente, ejecute el siguiente comando.
knife azurerm server list
Si todo está configurado correctamente, verá una lista de imágenes de Azure disponibles en desplazamiento.
¡ Enhorabuena! La estación de trabajo está configurada.
Crear una guía

Chef usa las guías para definir un conjunto de comandos que desea ejecutar en el cliente administrado. La creación
de un libro de recetas es un proceso sencillo, solo haya que usar el comando chef generate cookbook para
generar la plantilla del libro de recetas. Dicho libro de recetas es para un servidor web que implementa IIS
automáticamente.
En el directorio C:\Chef, ejecute el siguiente comando.
chef generate cookbook webserver
Este comando genera un conjunto de archivos en el directorio C:\Chef\cookbooks\webserver. A continuación,

defina el conjunto de comandos que el cliente Chef ejecutara en la máquina virtual administrada.
Los comandos se almacenan en el archivo default.rb. En dicho archivo, defina un conjunto de comandos que instala
IIS, inicia IIS y copia un archivo de plantilla en la carpeta wwwroot.
Modifique el archivo C:\chef\cookbooks\webserver\recipes\default.rb y agregue las siguientes líneas.
powershell_script 'Install IIS' do
action :run
code 'add-windowsfeature Web-Server'
end
service 'w3svc' do
action [ :enable, :start ]
end
template 'c:\inetpub\wwwroot\Default.htm' do
source 'Default.htm.erb'
rights :read, 'Everyone'
end
Cuando haya terminado, guarde el archivo.
Crear una plantilla

En este paso, generará un archivo de plantilla que se va a utilizar como la página default.html.
Ejecute el siguiente comando para generar la plantilla:
chef generate template webserver Default.htm
Vaya al archivo C:\chef\cookbooks\webserver\templates\default\Default.htm.erb . Edite el archivo agregando el

código HTML simple "Hello World" y guarde el archivo.
Cargar la guía en el servidor Chef

En este paso se realiza una copia de la guía que se ha creado en el equipo local y se cargamos en el servidor
hospedado de Chef. Una vez que se carga, la guía aparece en la pestaña Policy (Directiva).
knife cookbook upload webserver
Implementar una máquina virtual con Knife Azure

Implemente una máquina virtual de Azure y aplique la guía "Webserver", que instalará el servicio web de IIS y la
página web predeterminada.
Para ello, use el comando knife azurerm server create.
A continuación aparece un ejemplo del comando.
knife azurerm server create `
--azure-resource-group-name rg-chefdeployment `
--azure-storage-account store `
--azure-vm-name chefvm `
--azure-vm-size 'Standard_DS2_v2' `
--azure-service-location 'westus' `
--azure-image-reference-offer 'WindowsServer' `
--azure-image-reference-publisher 'MicrosoftWindowsServer' `
--azure-image-reference-sku '2016-Datacenter' `
--azure-image-reference-version 'latest' `
-x myuser -P myPassword123 `
--tcp-endpoints '80,3389' `
--chef-daemon-interval 1 `
-r "recipe[webserver]"
En el ejemplo anterior se creará una máquina virtual Standard_DS2_v2 con Windows Server 2016 instalado en la
región Oeste de EE. UU. Sustituir sus variables concretas y ejecutar.
NOTE
Mediante la línea de comandos, también estoy automatizando mis reglas de filtro de red de punto de conexión mediante el
parámetro –tcp-endpoints. He abierto los puertos 80 y 3389 para proporcionar acceso a la página web y la sesión de RDP.
Cuando haya ejecutado el comando, vaya a Azure Portal y verá que el equipo comienza a realizar el
aprovisionamiento.
A continuación aparecerá el símbolo del sistema:
Una vez completada la implementación, la dirección IP pública de la nueva máquina virtual se mostrará al finalizar
la implementación; puede copiarla y pegarla en un explorador web y ver el sitio web que ha implementado. Al
implementar la máquina virtual, hemos abierto el puerto 80, por lo que debería estar disponible externamente.
En este ejemplo se utiliza código HTML creativo.
También puede ver el estado del nodo en Chef Manage.
No olvide que también puede conectarse mediante una sesión RDP desde Azure Portal a través del puerto 3389.
Gracias. Empiece hoy su viaje de su infraestructura como código con Azure.
Windows en Azure mediante Java
creación, la administración y la eliminación de recursos de máquina virtual con Java. Aprenderá a:
Creación de un proyecto de Maven
Adición de dependencias
Crear credenciales
Crear recursos
Eliminar recursos
Creación de un proyecto de Maven

1. Si aún no lo ha hecho, instale Java.
2. Instale Maven.
3. Cree una nueva carpeta y el proyecto:
mkdir java-azure-test
cd java-azure-test
mvn archetype:generate -DgroupId=com.fabrikam -DartifactId=testAzureApp -DarchetypeArtifactId=maven-

archetype-quickstart -DinteractiveMode=false
Adición de dependencias
1. En la carpeta testAzureApp , abra el archivo pom.xml y agregue la configuración de compilación al
<proyecto> para habilitar la compilación de la aplicación:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<configuration>
<mainClass>com.fabrikam.testAzureApp.App</mainClass>
</configuration>
</plugin>
</plugins>
</build>
2. Agregue las dependencias necesarias para acceder al SDK de Java de Azure.

<dependency>
<groupId>com.microsoft.azure</groupId>
<artifactId>azure</artifactId>
<version>1.1.0</version>
</dependency>
<dependency>
<artifactId>azure-mgmt-compute</artifactId>
</dependency>
<dependency>
<artifactId>azure-mgmt-resources</artifactId>
</dependency>
<dependency>
<artifactId>azure-mgmt-network</artifactId>
</dependency>
<dependency>
<groupId>com.squareup.okio</groupId>
<artifactId>okio</artifactId>
</dependency>
<dependency>
<groupId>com.nimbusds</groupId>
<artifactId>nimbus-jose-jwt</artifactId>
<version>3.6</version>
</dependency>
<dependency>
<groupId>net.minidev</groupId>
<artifactId>json-smart</artifactId>
<version>1.0.6.3</version>
</dependency>
<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
</dependency>
3. Guarde el archivo.
Crear credenciales
Antes de empezar este paso, asegúrese de que tiene acceso a una entidad de servicio de Active Directory. También
debe registrar el identificador de aplicación, la clave de autenticación y el identificador del inquilino que necesitará
en un paso posterior.
1. Cree un archivo denominado " azureauth.properties " y agregar estas propiedades:
tenant=<tenant-id>

2. Guarde el archivo.
3. Establezca una variable de entorno denominada "AZURE_AUTH_LOCATION" en el shell con la ruta de
acceso completa al archivo de autenticación.
1. Abra el archivo App.java en src\main\java\com\fabrikam y asegúrese de que esta instrucción del paquete
esté en la parte superior:
package com.fabrikam.testAzureApp;
2. En la instrucción del paquete, agregue estas instrucciones de importación:
import com.microsoft.azure.management.Azure;
import com.microsoft.azure.management.compute.AvailabilitySet;
import com.microsoft.azure.management.compute.AvailabilitySetSkuTypes;
import com.microsoft.azure.management.compute.CachingTypes;
import com.microsoft.azure.management.compute.InstanceViewStatus;
import com.microsoft.azure.management.compute.DiskInstanceView;
import com.microsoft.azure.management.compute.VirtualMachine;
import com.microsoft.azure.management.compute.VirtualMachineSizeTypes;
import com.microsoft.azure.management.network.PublicIPAddress;
import com.microsoft.azure.management.network.Network;
import com.microsoft.azure.management.network.NetworkInterface;
import com.microsoft.azure.management.resources.ResourceGroup;
import com.microsoft.azure.management.resources.fluentcore.arm.Region;
import com.microsoft.azure.management.resources.fluentcore.model.Creatable;
import com.microsoft.rest.LogLevel;
import java.io.File;
import java.util.Scanner;
3. Para crear las credenciales de Active Directory que necesita para realizar solicitudes, agregue este código al
método Main de la clase App:
try {
final File credFile = new File(System.getenv("AZURE_AUTH_LOCATION"));
Azure azure = Azure.configure()
.withLogLevel(LogLevel.BASIC)
.authenticate(credFile)
.withDefaultSubscription();
} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}
Crear recursos
Creación del grupo de recursos
Para especificar los valores de la aplicación y crear el grupo de recursos, agregue este código al bloque Try del
método Main:
System.out.println("Creating resource group...");
ResourceGroup resourceGroup = azure.resourceGroups()
.define("myResourceGroup")
.withRegion(Region.US_EAST)
.create();
Creación del conjunto de disponibilidad

Para crear el conjunto de disponibilidad, agregue este código al bloque Try del método Main:
System.out.println("Creating availability set...");

AvailabilitySet availabilitySet = azure.availabilitySets()
.define("myAvailabilitySet")
.withExistingResourceGroup("myResourceGroup")
.withSku(AvailabilitySetSkuTypes.MANAGED)
.create();
Crear la dirección IP pública

Para crear la dirección IP pública de la máquina virtual, agregue este código al bloque Try del método Main:
System.out.println("Creating public IP address...");

PublicIPAddress publicIPAddress = azure.publicIPAddresses()
.define("myPublicIP")
.withDynamicIP()
.create();
Crear la red virtual

Para crear una subred y una red virtual, agregue este código al bloque Try del método Main:
System.out.println("Creating virtual network...");

Network network = azure.networks()
.define("myVN")
.withAddressSpace("10.0.0.0/16")
.withSubnet("mySubnet","10.0.0.0/24")
.create();
Creación de la interfaz de red

Para crear una interfaz de red, agregue este código al bloque Try del método Main:
System.out.println("Creating network interface...");
NetworkInterface networkInterface = azure.networkInterfaces()
.define("myNIC")
.withExistingPrimaryNetwork(network)
.withSubnet("mySubnet")
.withPrimaryPrivateIPAddressDynamic()
.withExistingPrimaryPublicIPAddress(publicIPAddress)
.create();

Para crear la máquina virtual, agregue este código al bloque Try del método Main:
System.out.println("Creating virtual machine...");

VirtualMachine virtualMachine = azure.virtualMachines()
.define("myVM")
.withExistingPrimaryNetworkInterface(networkInterface)
.withLatestWindowsImage("MicrosoftWindowsServer", "WindowsServer", "2012-R2-Datacenter")
.withAdminUsername("azureuser")
.withAdminPassword("Azure12345678")
.withComputerName("myVM")
.withExistingAvailabilitySet(availabilitySet)
.withSize("Standard_DS1")
.create();
Scanner input = new Scanner(System.in);
System.out.println("Press enter to get information about the VM...");
input.nextLine();
NOTE
En este tutorial se crea una máquina virtual donde se ejecuta una versión del sistema operativo Windows Server. Para más
información sobre cómo seleccionar otras imágenes, consulte Seleccione y navegue por imágenes de máquina virtual de
Azure con PowerShell y la CLI de Azure.
Si desea usar un disco existente en lugar de una imagen de Marketplace, use este código:
ManagedDisk managedDisk = azure.disks.define("myosdisk")

.withWindowsFromVhd("https://mystorage.blob.core.windows.net/vhds/myosdisk.vhd")
.withSizeInGB(128)
.withSku(DiskSkuTypes.PremiumLRS)
.create();
azure.virtualMachines.define("myVM")
.withExistingPrimaryNetworkInterface(networkInterface)
.withSpecializedOSDisk(managedDisk, OperatingSystemTypes.Windows)
.withExistingAvailabilitySet(availabilitySet)
.withSize(VirtualMachineSizeTypes.StandardDS1)
.create();
Cuando tenga que hacerlas con la máquina virtual, deberá obtener una instancia de ella. Agregue este código al
bloque Try del método Main:
VirtualMachine vm = azure.virtualMachines().getByResourceGroup("myResourceGroup", "myVM");

Para obtener información sobre la máquina virtual, agregue este código al bloque Try del método Main:
System.out.println("hardwareProfile");
System.out.println(" vmSize: " + vm.size());
System.out.println("storageProfile");
System.out.println(" imageReference");
System.out.println(" publisher: " + vm.storageProfile().imageReference().publisher());
System.out.println(" offer: " + vm.storageProfile().imageReference().offer());
System.out.println(" sku: " + vm.storageProfile().imageReference().sku());
System.out.println(" version: " + vm.storageProfile().imageReference().version());
System.out.println(" osDisk");
System.out.println(" osType: " + vm.storageProfile().osDisk().osType());
System.out.println(" name: " + vm.storageProfile().osDisk().name());
System.out.println(" createOption: " + vm.storageProfile().osDisk().createOption());
System.out.println(" caching: " + vm.storageProfile().osDisk().caching());
System.out.println("osProfile");
System.out.println(" computerName: " + vm.osProfile().computerName());
System.out.println(" adminUserName: " + vm.osProfile().adminUsername());
System.out.println(" provisionVMAgent: " + vm.osProfile().windowsConfiguration().provisionVMAgent());
System.out.println(" enableAutomaticUpdates: " +
vm.osProfile().windowsConfiguration().enableAutomaticUpdates());
System.out.println("networkProfile");
System.out.println(" networkInterface: " + vm.primaryNetworkInterfaceId());
System.out.println("vmAgent");
System.out.println(" vmAgentVersion: " + vm.instanceView().vmAgent().vmAgentVersion());
System.out.println(" statuses");
for(InstanceViewStatus status : vm.instanceView().vmAgent().statuses()) {
System.out.println(" code: " + status.code());
System.out.println(" displayStatus: " + status.displayStatus());
System.out.println(" message: " + status.message());
System.out.println(" time: " + status.time());
}
System.out.println("disks");
for(DiskInstanceView disk : vm.instanceView().disks()) {
System.out.println(" name: " + disk.name());
System.out.println(" statuses");
for(InstanceViewStatus status : disk.statuses()) {
System.out.println(" time: " + status.time());
}
}
System.out.println("VM general status");
System.out.println(" provisioningStatus: " + vm.provisioningState());
System.out.println(" id: " + vm.id());
System.out.println(" name: " + vm.name());
System.out.println(" type: " + vm.type());
System.out.println("VM instance status");
for(InstanceViewStatus status : vm.instanceView().statuses()) {
}
System.out.println("Press enter to continue...");
input.nextLine();

Para detener la máquina virtual sin desasignarla, agregue este código al bloque Try del método Main:
System.out.println("Stopping vm...");
vm.powerOff();
input.nextLine();
Si desea desasignar la máquina virtual, cambie la llamada de PowerOff por este código:
vm.deallocate();

Para iniciar la máquina virtual, agregue este código al bloque Try del método Main:
System.out.println("Starting vm...");
vm.start();
input.nextLine();

Para cambiar el tamaño de la máquina virtual, agregue este código al bloque Try del método Main:
System.out.println("Resizing vm...");
vm.update()
.withSize(VirtualMachineSizeTypes.STANDARD_DS2)
.apply();
input.nextLine();

Para agregar un disco de datos a la máquina virtual, agregue este código al bloque Try del método Main para
agregar un disco de datos de 2 GB de tamaño, tener un LUN de 0 y un tipo de almacenamiento en caché de lectura
y escritura:
System.out.println("Adding data disk...");

vm.update()
.withNewDataDisk(2, 0, CachingTypes.READ_WRITE)
.apply();
System.out.println("Press enter to delete resources...");
input.nextLine();
Eliminar recursos
1. Para eliminar el grupo de recursos, agregue este código al bloque Try del método Main:
System.out.println("Deleting resources...");
azure.resourceGroups().deleteByName("myResourceGroup");
2. Guarde el archivo App.java.
1. Para ejecutar la aplicación, use este comando de Maven:
mvn compile exec:java
Pasos siguientes
Para obtener más información sobre cómo usar las bibliotecas de Azure para Java.
Windows en Azure con Python
creación, la administración y la eliminación de recursos de máquina virtual con Python. Aprenderá a:
Instalar paquetes
Crear credenciales
Crear recursos
Eliminar recursos

1. Si aún no lo ha hecho, instale Visual Studio. Seleccione Desarrollo de Python en la página Cargas de trabajo y
haga clic en Instalar. En el resumen, verá que Python 3 de 64 bits (3.6.0) se selecciona automáticamente. Si
ya ha instalado Visual Studio, puede agregar la carga de trabajo de Python con el selector de Visual Studio.
2. Después de instalar e iniciar Visual Studio, haga clic en Archivo > Nuevo > Proyecto.
3. Haga clic en Plantillas > Python > Python Application (Aplicación de Python), escriba myPythonProject en
el nombre del proyecto, seleccione la su ubicación y haga clic en Aceptar.
Instalar paquetes
1. En el Explorador de soluciones, bajo myPythonProject, haga clic con el botón derecho en Python
Environments (Entornos de Python) y seleccione Add virtual environment (Agregar entorno virtual).
2. En la pantalla Add virtual environment (Agregar entorno virtual), acepte el nombre predeterminado de env,
asegúrese de que Python 3.6 (64 bits) está seleccionada para el intérprete de base y haga clic en Crear.
3. Haga clic con el botón derecho en el entorno de env que creó, haga clic en Install Python Package (Instalar
paquete de Python), escriba azure en el cuadro de búsqueda y presione Entrar.
Debería ver en las ventanas de salida que se han instalado correctamente los paquetes de azure.
Crear credenciales
Antes de empezar este paso, asegúrese de que tiene una entidad de servicio de Active Directory. También debe
registrar el identificador de aplicación, la clave de autenticación y el identificador del inquilino que necesitará en un
paso posterior.
1. Abra el archivo myPythonProject.py que se creó y agregue este código para habilitar la ejecución de la
aplicación:
if __name__ == "__main__":
2. Para importar el código necesario, agregue estas instrucciones a la parte superior del archivo .py:
from azure.common.credentials import ServicePrincipalCredentials

from azure.mgmt.resource import ResourceManagementClient
from azure.mgmt.compute import ComputeManagementClient
from azure.mgmt.network import NetworkManagementClient
from azure.mgmt.compute.models import DiskCreateOption
3. A continuación, en el archivo .py, agregue variables después de las instrucciones de importación para
especificar los valores comunes que se usan en el código:
SUBSCRIPTION_ID = 'subscription-id'
GROUP_NAME = 'myResourceGroup'
LOCATION = 'westus'
VM_NAME = 'myVM'
Reemplace subscription-id por el identificador de la suscripción.

4. Para crear las credenciales de Active Directory que necesita para realizar solicitudes, agregue esta función
después de las variables en el archivo .py:
def get_credentials():
credentials = ServicePrincipalCredentials(
client_id = 'application-id',
secret = 'authentication-key',
tenant = 'tenant-id'
)
return credentials
Reemplace application-id, authentication-key y tenant-id por los valores que recopiló anteriormente al
crear la entidad de servicio de Azure Active Directory.
5. Para llamar a la función que agregó anteriormente, agregue este código bajo la instrucción if al final del
archivo .py:
credentials = get_credentials()
Crear recursos
Inicialización de los clientes de administración
Se necesitan clientes de administración para crear y administrar los recursos con el SDK de Python en Azure. Para
crear los clientes de administración, agregue este código bajo la instrucción if al final del archivo .py:
resource_group_client = ResourceManagementClient(
credentials,
SUBSCRIPTION_ID
)
network_client = NetworkManagementClient(
credentials,
SUBSCRIPTION_ID
)
compute_client = ComputeManagementClient(
credentials,
SUBSCRIPTION_ID
)
Creación de la máquina virtual y los recursos compatibles
1. Para crear un grupo de recursos, agregue esta función después de las variables en el archivo .py:
def create_resource_group(resource_group_client):
resource_group_params = { 'location':LOCATION }
resource_group_result = resource_group_client.resource_groups.create_or_update(
GROUP_NAME,
resource_group_params
)
archivo .py:
create_resource_group(resource_group_client)
input('Resource group created. Press enter to continue...')
1. Para crear un conjunto de disponibilidad, agregue esta función después de las variables en el archivo .py:
def create_availability_set(compute_client):
avset_params = {
'location': LOCATION,
'sku': { 'name': 'Aligned' },
'platform_fault_domain_count': 3
}
availability_set_result = compute_client.availability_sets.create_or_update(
GROUP_NAME,
'myAVSet',
avset_params
)
archivo .py:
create_availability_set(compute_client)
print("------------------------------------------------------")
input('Availability set created. Press enter to continue...')

1. Para crear una dirección IP pública para la máquina virtual, agregue esta función después de las variables en
el archivo .py:
def create_public_ip_address(network_client):
public_ip_addess_params = {
'public_ip_allocation_method': 'Dynamic'
}
creation_result = network_client.public_ip_addresses.create_or_update(
GROUP_NAME,
'myIPAddress',
public_ip_addess_params
)
return creation_result.result()
archivo .py:
creation_result = create_public_ip_address(network_client)
print("------------------------------------------------------")
print(creation_result)
input('Press enter to continue...')
1. Para crear una red virtual, agregue esta función después de las variables en el archivo .py:
def create_vnet(network_client):
vnet_params = {
'address_space': {
'address_prefixes': ['10.0.0.0/16']
}
}
creation_result = network_client.virtual_networks.create_or_update(
GROUP_NAME,
'myVNet',
vnet_params
)
archivo .py:
creation_result = create_vnet(network_client)
print("------------------------------------------------------")
3. Para agregar una subred a la red virtual, agregue esta función después de las variables en el archivo .py:
def create_subnet(network_client):
subnet_params = {
'address_prefix': '10.0.0.0/24'
}
creation_result = network_client.subnets.create_or_update(
GROUP_NAME,
'myVNet',
'mySubnet',
subnet_params
)
archivo .py:
creation_result = create_subnet(network_client)
print("------------------------------------------------------")
1. Para crear una interfaz de red, agregue esta función después de las variables en el archivo .py:
def create_nic(network_client):
subnet_info = network_client.subnets.get(
GROUP_NAME,
'myVNet',
'mySubnet'
)
publicIPAddress = network_client.public_ip_addresses.get(
GROUP_NAME,
'myIPAddress'
)
nic_params = {
'ip_configurations': [{
'name': 'myIPConfig',
'public_ip_address': publicIPAddress,
'subnet': {
'id': subnet_info.id
}
}]
}
creation_result = network_client.network_interfaces.create_or_update(
GROUP_NAME,
'myNic',
nic_params
)
archivo .py:
creation_result = create_nic(network_client)
print("------------------------------------------------------")
1. Para crear la máquina virtual, agregue esta función después de las variables en el archivo .py:
def create_vm(network_client, compute_client):

nic = network_client.network_interfaces.get(
GROUP_NAME,
'myNic'
)
avset = compute_client.availability_sets.get(
GROUP_NAME,
'myAVSet'
)
vm_parameters = {
'os_profile': {
'computer_name': VM_NAME,
'admin_username': 'azureuser',
'admin_password': 'Azure12345678'
},
'hardware_profile': {
'vm_size': 'Standard_DS1'
},
'storage_profile': {
'image_reference': {
'publisher': 'MicrosoftWindowsServer',
'offer': 'WindowsServer',
'sku': '2012-R2-Datacenter',
'version': 'latest'
}
},
'network_profile': {
'network_interfaces': [{
'id': nic.id
}]
},
'availability_set': {
'id': avset.id
}
}
creation_result = compute_client.virtual_machines.create_or_update(
GROUP_NAME,
VM_NAME,
vm_parameters
)
NOTE
En este tutorial se crea una máquina virtual donde se ejecuta una versión del sistema operativo Windows Server. Para
más información sobre cómo seleccionar otras imágenes, consulte Seleccione y navegue por imágenes de máquina
virtual de Azure con PowerShell y la CLI de Azure.
archivo .py:
creation_result = create_vm(network_client, compute_client)

print("------------------------------------------------------")
1. Para obtener información acerca de la máquina virtual, agregue esta función después de las variables en el
archivo .py:
def get_vm(compute_client):
vm = compute_client.virtual_machines.get(GROUP_NAME, VM_NAME, expand='instanceView')
print("hardwareProfile")
print(" vmSize: ", vm.hardware_profile.vm_size)
print("\nstorageProfile")
print(" imageReference")
print(" publisher: ", vm.storage_profile.image_reference.publisher)
print(" offer: ", vm.storage_profile.image_reference.offer)
print(" sku: ", vm.storage_profile.image_reference.sku)
print(" version: ", vm.storage_profile.image_reference.version)
print(" osDisk")
print(" osType: ", vm.storage_profile.os_disk.os_type.value)
print(" name: ", vm.storage_profile.os_disk.name)
print(" createOption: ", vm.storage_profile.os_disk.create_option.value)
print(" caching: ", vm.storage_profile.os_disk.caching.value)
print("\nosProfile")
print(" computerName: ", vm.os_profile.computer_name)
print(" adminUsername: ", vm.os_profile.admin_username)
print(" provisionVMAgent: {0}".format(vm.os_profile.windows_configuration.provision_vm_agent))
print(" enableAutomaticUpdates:
{0}".format(vm.os_profile.windows_configuration.enable_automatic_updates))
print("\nnetworkProfile")
for nic in vm.network_profile.network_interfaces:
print(" networkInterface id: ", nic.id)
print("\nvmAgent")
print(" vmAgentVersion", vm.instance_view.vm_agent.vm_agent_version)
print(" statuses")
for stat in vm_result.instance_view.vm_agent.statuses:
print(" code: ", stat.code)
print(" displayStatus: ", stat.display_status)
print(" message: ", stat.message)
print(" time: ", stat.time)
print("\ndisks");
for disk in vm.instance_view.disks:
print(" name: ", disk.name)
print(" statuses")
for stat in disk.statuses:
print(" time: ", stat.time)
print("\nVM general status")
print(" provisioningStatus: ", vm.provisioning_state)
print(" id: ", vm.id)
print(" name: ", vm.name)
print(" type: ", vm.type)
print(" location: ", vm.location)
print("\nVM instance status")
for stat in vm.instance_view.statuses:
archivo .py:
get_vm(compute_client)
print("------------------------------------------------------")

1. Para detener la máquina virtual sin desasignarla, agregue esta función después de las variables en el archivo
.py:
def stop_vm(compute_client):
compute_client.virtual_machines.power_off(GROUP_NAME, VM_NAME)
Si desea desasignar la máquina virtual, cambie la llamada de power_off por este código:
compute_client.virtual_machines.deallocate(GROUP_NAME, VM_NAME)
archivo .py:
stop_vm(compute_client)

1. Para iniciar la máquina virtual, agregue esta función después de las variables en el archivo .py:
def start_vm(compute_client):
compute_client.virtual_machines.start(GROUP_NAME, VM_NAME)
archivo .py:
start_vm(compute_client)

1. Para cambiar el tamaño de la máquina virtual, agregue esta función después de las variables en el archivo
.py:
def update_vm(compute_client):
vm = compute_client.virtual_machines.get(GROUP_NAME, VM_NAME)
vm.hardware_profile.vm_size = 'Standard_DS3'
update_result = compute_client.virtual_machines.create_or_update(
GROUP_NAME,
VM_NAME,
vm
)
return update_result.result()
archivo .py:
update_result = update_vm(compute_client)
print("------------------------------------------------------")
print(update_result)

Las máquinas virtuales pueden tener uno o más discos de datos que se almacenen en discos duros virtuales.
1. Para agregar un disco de datos a la máquina virtual, agregue esta función después de las variables en el
archivo .py:
def add_datadisk(compute_client):
disk_creation = compute_client.disks.create_or_update(
GROUP_NAME,
'myDataDisk1',
{
'disk_size_gb': 1,
'creation_data': {
'create_option': DiskCreateOption.empty
}
}
)
data_disk = disk_creation.result()
vm = compute_client.virtual_machines.get(GROUP_NAME, VM_NAME)
add_result = vm.storage_profile.data_disks.append({
'lun': 1,
'name': 'myDataDisk1',
'create_option': DiskCreateOption.attach,
'managed_disk': {
'id': data_disk.id
}
})
add_result = compute_client.virtual_machines.create_or_update(
GROUP_NAME,
VM_NAME,
vm)
return add_result.result()
archivo .py:
add_result = add_datadisk(compute_client)
print("------------------------------------------------------")
print(add_result)
Eliminar recursos
1. Para eliminar un grupo de recursos y todos los recursos, agregue esta función después de las variables en el
archivo .py:
def delete_resources(resource_group_client):
resource_group_client.resource_groups.delete(GROUP_NAME)
archivo .py:
delete_resources(resource_group_client)
3. Guarde myPythonProject.py.
1. Para ejecutar la aplicación de consola, haga clic en Iniciar en Visual Studio.
2. Después de la devolución de cada recurso, presione Entrar. En la información de estado, debería ver el
estado de aprovisionamiento Correcto. Después de crear la máquina virtual, tendrá la oportunidad de
eliminar todos los recursos creados. Antes de presionar Entrar para comenzar la eliminación de recursos,
puede dedicarle unos minutos a comprobar si se han creado en Azure Portal. Si tiene abierto Azure Portal,
tendrá que actualizar la hoja para ver los recursos nuevos.
Cuando termine la aplicación, la eliminación de los recursos y el grupo de recursos puede tardar unos
minutos.
Pasos siguientes
Si se han producido problemas durante la implementación, el paso siguiente será consultar Solución de
problemas de implementaciones de grupo de recursos con Azure Portal
Más información acerca de la biblioteca de Python de Azure
Creación de una máquina virtual Windows con una
plantilla de Resource Manager
Aprenda a crear una máquina virtual Windows mediante una plantilla de Azure Resource Manager y Azure
PowerShell desde Azure Cloud Shell. La plantilla usada en este artículo implementa una sola máquina virtual que
ejecuta Windows Server en una nueva red virtual con una sola subred. Para la creación de una máquina virtual
Linux, consulte Procedimiento para crear una máquina virtual Linux con plantillas de Azure Resource Manager.

La creación de una máquina virtual de Azure normalmente incluye dos pasos:
Cree un grupo de recursos. Un grupo de recursos de Azure es un contenedor lógico en el que se implementan
y se administran los recursos de Azure. Se debe crear un grupo de recursos antes de una máquina virtual.
Cree una máquina virtual.
En el siguiente ejemplo se crea una máquina virtual a partir de una plantilla de inicio rápido de Azure. Esta es una
copia de la plantilla:
{
"parameters": {
"adminUsername": {
"type": "string",
"metadata": {
"description": "Username for the Virtual Machine."
}
},
"adminPassword": {
"type": "securestring",
"metadata": {
"description": "Password for the Virtual Machine."
}
},
"dnsLabelPrefix": {
"type": "string",
"metadata": {
"description": "Unique DNS Name for the Public IP used to access the Virtual Machine."
}
},
"windowsOSVersion": {
"type": "string",
"defaultValue": "2016-Datacenter",
"allowedValues": [
"2008-R2-SP1",
"2012-Datacenter",
"2012-R2-Datacenter",
"2016-Nano-Server",
"2016-Datacenter-with-Containers",
"2016-Datacenter",
"2019-Datacenter"
],
"metadata": {
"description": "The Windows version for the VM. This will pick a fully patched image of this given
Windows version."
}
}
},
"vmSize": {
"type": "string",
"defaultValue": "Standard_A2_v2",
"metadata": {
"description": "Size of the virtual machine."
}
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for all resources."
}
}
},
"variables": {
"storageAccountName": "[concat(uniquestring(resourceGroup().id), 'sawinvm')]",
"nicName": "myVMNic",
"addressPrefix": "10.0.0.0/16",
"subnetName": "Subnet",
"subnetPrefix": "10.0.0.0/24",
"publicIPAddressName": "myPublicIP",
"vmName": "SimpleWinVM",
"virtualNetworkName": "MyVNET",
"subnetRef": "[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('virtualNetworkName'),
variables('subnetName'))]",
"networkSecurityGroupName": "default-NSG"
},
"resources": [
{
"type": "Microsoft.Storage/storageAccounts",
"apiVersion": "2018-11-01",
"name": "[variables('storageAccountName')]",
"location": "[parameters('location')]",
"sku": {
"name": "Standard_LRS"
},
"kind": "Storage",
"properties": {}
},
{
"type": "Microsoft.Network/publicIPAddresses",
"apiVersion": "2018-11-01",
"name": "[variables('publicIPAddressName')]",
"properties": {
"publicIPAllocationMethod": "Dynamic",
"dnsSettings": {
"domainNameLabel": "[parameters('dnsLabelPrefix')]"
}
}
},
{
"comments": "Default Network Security Group for template",
"type": "Microsoft.Network/networkSecurityGroups",
"apiVersion": "2019-08-01",
"name": "[variables('networkSecurityGroupName')]",
"properties": {
"securityRules": [
{
"name": "default-allow-3389",
"properties": {
"priority": 1000,
"access": "Allow",
"direction": "Inbound",
"destinationPortRange": "3389",
"protocol": "Tcp",
"protocol": "Tcp",
"sourcePortRange": "*",
"sourceAddressPrefix": "*",
"destinationAddressPrefix": "*"
}
}
]
}
},
{
"type": "Microsoft.Network/virtualNetworks",
"apiVersion": "2018-11-01",
"name": "[variables('virtualNetworkName')]",
"dependsOn": [
"[resourceId('Microsoft.Network/networkSecurityGroups', variables('networkSecurityGroupName'))]"
],
"properties": {
"addressSpace": {
"addressPrefixes": [
"[variables('addressPrefix')]"
]
},
"subnets": [
{
"name": "[variables('subnetName')]",
"properties": {
"addressPrefix": "[variables('subnetPrefix')]",
"networkSecurityGroup": {
"id": "[resourceId('Microsoft.Network/networkSecurityGroups',
variables('networkSecurityGroupName'))]"
}
}
}
]
}
},
{
"type": "Microsoft.Network/networkInterfaces",
"apiVersion": "2018-11-01",
"name": "[variables('nicName')]",
"dependsOn": [
"[resourceId('Microsoft.Network/publicIPAddresses/', variables('publicIPAddressName'))]",
"[resourceId('Microsoft.Network/virtualNetworks/', variables('virtualNetworkName'))]"
],
"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"privateIPAllocationMethod": "Dynamic",
"publicIPAddress": {
"id": "[resourceId('Microsoft.Network/publicIPAddresses',variables('publicIPAddressName'))]"
},
"subnet": {
"id": "[variables('subnetRef')]"
}
}
}
]
}
},
{
"apiVersion": "2018-10-01",
"name": "[variables('vmName')]",
"dependsOn": [
"[resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]",
"[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
],
"properties": {
"vmSize": "[parameters('vmSize')]"
},
"osProfile": {
"computerName": "[variables('vmName')]",
},
"storageProfile": {
"imageReference": {
"sku": "[parameters('windowsOSVersion')]",
"version": "latest"
},
"osDisk": {
},
"dataDisks": [
{
"diskSizeGB": 1023,
"lun": 0,
"createOption": "Empty"
}
]
},
"networkProfile": {
{
"id": "[resourceId('Microsoft.Network/networkInterfaces',variables('nicName'))]"
}
]
},
"diagnosticsProfile": {
"bootDiagnostics": {
"enabled": true,
"storageUri": "[reference(resourceId('Microsoft.Storage/storageAccounts/',
variables('storageAccountName'))).primaryEndpoints.blob]"
}
}
}
}
],
"outputs": {
"hostname": {
"type": "string",
"value": "[reference(variables('publicIPAddressName')).dnsSettings.fqdn]"
}
}
}
Para ejecutar el script de PowerShell, seleccione Pruébelo para abrir el shell de Azure Cloud. Para pegar el script,
haga clic con el botón derecho en el shell y luego seleccione Pegar:
$resourceGroupName = Read-Host -Prompt "Enter the Resource Group name"
$location = Read-Host -Prompt "Enter the location (i.e. centralus)"
$adminUsername = Read-Host -Prompt "Enter the administrator username"
$adminPassword = Read-Host -Prompt "Enter the administrator password" -AsSecureString
$dnsLabelPrefix = Read-Host -Prompt "Enter an unique DNS name for the public IP"
New-AzResourceGroup -Name $resourceGroupName -Location "$location"

New-AzResourceGroupDeployment `
-ResourceGroupName $resourceGroupName `
-TemplateUri "https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/101-vm-simple-
windows/azuredeploy.json" `
-adminUsername $adminUsername `
-adminPassword $adminPassword `
-dnsLabelPrefix $dnsLabelPrefix
(Get-AzVm -ResourceGroupName $resourceGroupName).name
Si decide instalar y usar PowerShell de forma local en lugar de en el shell de Azure Cloud, en este tutorial
necesitará el módulo de Azure PowerShell. Ejecute Get-Module -ListAvailable Az para encontrar la versión. Si
necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si PowerShell se ejecuta localmente,
también debe ejecutar Connect-AzAccount para crear una conexión con Azure.
En el ejemplo anterior, especificó una plantilla almacenada en GitHub. También puede descargar o crear una
plantilla y especificar la ruta de acceso local con el parámetro --template-file .
Estos son algunos recursos adicionales:
Para aprender a desarrollar plantillas de Resource Manager, consulte la documentación de Azure Resource
Manager.
Para ver los esquemas de la máquina virtual de Azure, consulte Referencia sobre las plantillas de Azure.
Para ver más ejemplos de plantilla de máquina virtual, consulte Plantillas de inicio rápido de Azure.

El último comando de PowerShell del script anterior muestra el nombre de la máquina virtual. Para conectarse a
la máquina virtual, consulte Conexión a una máquina virtual de Azure donde se ejecuta Windows e inicio de
sesión en esta.
Pasos siguientes
Si se produjeron problemas con la implementación, consulte Solución de errores comunes de implementación
de Azure con Azure Resource Manager.
Aprenda a crear y administrar una máquina virtual en Creación y administración de máquinas virtuales
Windows con el módulo de Azure PowerShell.
Para más información sobre cómo crear plantillas, vea las propiedades y la sintaxis de JSON para los tipos de
recursos que ha implementado:
Microsoft.Network/publicIPAddresses
Microsoft.Network/virtualNetworks
Microsoft.Network/networkInterfaces
Microsoft.Compute/virtualMachines
Conexión a una máquina virtual de Azure donde se
ejecuta Windows e inicio de sesión en ella
Para iniciar una sesión de Escritorio remoto (RDP ) desde un escritorio de Windows, usará el botón Conectar de
Azure Portal. En primer lugar, conéctese a la máquina virtual e inicie sesión.
Para conectarse a una máquina virtual Windows desde un equipo Mac, debe instalar un cliente de RDP para
Mac como el Escritorio remoto de Microsoft.

1. Si aún no lo ha hecho, inicie sesión en el Azure Portal.
2. En el menú de la izquierda, seleccione Máquinas virtuales.
3. Seleccione la máquina virtual en la lista.
4. En la parte superior de la página de la máquina virtual, haga clic en Conectar.
5. En la página Conexión a la máquina virtual, seleccione la dirección IP y el puerto adecuados. En la
mayoría de los casos, se deben utilizar la dirección IP y el puerto predeterminados. Seleccione Descargar
archivo RDP. Si la máquina virtual tiene configurada una directiva Just-In-Time, primero deberá
seleccionar el botón Solicitar acceso para solicitar acceso antes de descargar el archivo RDP. Para
obtener más información sobre la directiva Just-in-Time, consulte Administración del acceso a máquina
virtual mediante Just-In-Time.
7. Aparecerá una advertencia que indica que el archivo .rdp procede de un editor desconocido. Se espera
que esto sea así. En la ventana Conexión a Escritorio remoto, haga clic en Conectar.
8. En la ventana Seguridad de Windows, seleccione Más opciones y, después, Usar otra cuenta. Escriba
las credenciales de una cuenta en la máquina virtual y haga clic en Aceptar.
Cuenta local: suele ser el nombre de usuario y la contraseña de la cuenta local que especificó al crear la
máquina virtual. En este caso, el dominio es el nombre de la máquina virtual y se escribe como
nombreDeVm\nombreDeUsuario.
Máquina virtual unida a dominio: si la máquina virtual pertenece a un dominio, escriba el nombre de
usuario con el formato Dominio\Nombre de usuario. La cuenta también debe estar en el grupo
Administradores o tener privilegios de acceso remoto a la máquina virtual.
Controlador de dominio: si la máquina virtual es un controlador de dominio, escriba el nombre de
usuario y la contraseña de una cuenta de administrador de dominio para ese dominio.
9. Haga clic en Sí para comprobar la identidad de la máquina virtual y finalizar el inicio de sesión.
TIP
Si el botón Conectar del portal está atenuado y no está conectado a Azure a través de una conexión Express
Route o VPN de sitio a sitio, deberá crear y asignar a la máquina virtual una dirección IP pública antes de poder
usar RDP. Para obtener más información, consulte Public IP addresses in Azure (Direcciones IP públicas en Azure).
Conexión a la máquina virtual mediante PowerShell

Si usa PowerShell y el módulo de Azure PowerShell está instalado, también puede establecer la conexión
mediante el cmdlet Get-AzRemoteDesktopFile , como se indica a continuación.
En este ejemplo, se iniciará inmediatamente la conexión RDP, con la aparición de mensajes similares a los
anteriores.
Get-AzRemoteDesktopFile -ResourceGroupName "RgName" -Name "VmName" -Launch
También puede guardar el archivo RDP para un uso futuro.
Get-AzRemoteDesktopFile -ResourceGroupName "RgName" -Name "VmName" -LocalPath "C:\Path\to\folder"
Pasos siguientes
Si tiene problemas con la conexión, consulte Troubleshoot Remote Desktop connections (Seleccionar problemas
con las conexiones del Escritorio remoto).
Ventaja para uso híbrido de Azure para Windows
Server
Para los clientes con Software Assurance, la ventaja para uso híbrido de Azure para Windows Server le permite
usar las licencias de Windows Server locales y ejecutar máquinas virtuales de Windows en Azure a bajo costo.
Puede usar la Ventaja híbrida de Azure para Windows Server para implementar nuevas máquinas virtuales con el
SO Windows. En este artículo se recorren los pasos necesarios para implementar nuevas máquinas virtuales con
la Ventaja híbrida de Azure para Windows Server y para actualizar las máquinas virtuales en funcionamiento
existentes. Para obtener más información acerca de los ahorros de costos y la concesión de licencias de la ventaja
para uso híbrido para Azure para Windows Server, vea la página de concesión de licencias de la ventaja para uso
híbrido de Azure para Windows Server.
IMPORTANT
Cada una de las licencias de dos procesadores o cada uno de los conjuntos de licencias de 16 núcleos tienen derecho a dos
instancias de hasta ocho núcleos o a una instancia de hasta 16 núcleos. La Ventaja híbrida de Azure para licencias de
Standard Edition solo podrá usarse una vez en el entorno local o en Azure. Las ventajas de Datacenter Edition permiten el
uso simultáneo de forma local y en Azure.
IMPORTANT
Ahora se admite el uso de la Ventaja híbrida de Azure para Windows Server con cualquier máquina virtual que ejecute el
sistema operativo Windows Server en todas las regiones, incluidas las máquinas virtuales con software adicional como SQL
Server o el software de catálogos de soluciones de terceros.
NOTE
Para las VM clásicas, solo se admite la implementación de una nueva VM desde imágenes personalizadas locales. Para
aprovechar las ventajas de las funcionalidades admitidas en este artículo, primero debe migrar las máquinas virtuales clásicas
al modelo de Resource Manager.
Formas de usar la ventaja para uso híbrido de Azure para Windows

Server
Hay varias maneras de utilizar máquinas virtuales de Windows con la ventaja para uso híbrido de Azure:
1. Puede implementar máquinas virtuales desde una de las imágenes de Windows Server en Azure Marketplace
proporcionadas.
2. Puede cargar una máquina virtual personalizada e implementar mediante una plantilla de Resource Manager o
Azure PowerShell.
3. Puede cambiar y convertir la máquina virtual existente entre la ejecución con la Ventaja híbrida de Azure o el
pago del coste adicional por Windows Server
4. También puede aplicar la Ventaja híbrida de Azure para Windows Server en un conjunto de escalado de
Crear una máquina virtual con la Ventaja híbrida de Azure para
Windows Server
Todas las imágenes basadas en sistemas operativos de Windows Server son compatibles con la Ventaja híbrida de
Azure para Windows Server. Puede usar imágenes compatibles con la plataforma de Azure o cargar sus propias
imágenes personalizadas de Windows Server.
Portal
Para crear una máquina virtual con la Ventaja híbrida de Azure para Windows Server, use el botón de alternancia
de la sección "Ahorrar dinero".
PowerShell
New-AzVm `
-Name "myVM" `
-LicenseType "Windows_Server"
CLI
az vm create \
--name myVM \
--location eastus \
--license-type Windows_Server
Plantilla
En las plantillas de Resource Manager, se debe especificar un parámetro licenseType adicional. Puede obtener
más información sobre la creación de plantillas de Azure Resource Manager.
"properties": {
"licenseType": "Windows_Server",
"vmSize": "[variables('vmSize')]"
}
Conversión de una máquina virtual existente con la Ventaja híbrida de

Azure para Windows Server
Si tiene una máquina virtual existente que le gustaría convertir para aprovechar la Ventaja híbrida de Azure para
Windows Server, puede actualizar el tipo de licencia de dicha máquina siguiendo las instrucciones que se indican a
continuación.
NOTE
Cuando se cambia el tipo de licencia de una máquina virtual, el sistema no se reinicia ni se interrumpe el servicio. Se trata
simplemente de una actualización de una marca de metadatos.
Portal
En la hoja de la máquina virtual del portal, puede actualizar la máquina virtual para usar la Ventaja híbrida de
Azure; para ello, seleccione la opción "Configuración" y cambie a la opción "Ventaja híbrida de Azure".
PowerShell
Conversión de máquinas virtuales existentes de Windows Server a la Ventaja híbrida de Azure para
Windows Server
$vm = Get-AzVM -ResourceGroup "rg-name" -Name "vm-name"

$vm.LicenseType = "Windows_Server"
Update-AzVM -ResourceGroupName rg-name -VM $vm
Conversión de nuevo de las máquinas virtuales de Windows Server con la ventaja al pago por uso
$vm = Get-AzVM -ResourceGroup "rg-name" -Name "vm-name"

$vm.LicenseType = "None"
Update-AzVM -ResourceGroupName rg-name -VM $vm
CLI
Conversión de máquinas virtuales existentes de Windows Server a la Ventaja híbrida de Azure para
Windows Server
az vm update --resource-group myResourceGroup --name myVM --set licenseType=Windows_Server
Cómo comprobar que la máquina virtual está usando la ventaja de licencia

Cuando haya implementado la máquina virtual mediante PowerShell, la plantilla de Resource Manager o el portal,
puede comprobar el valor en los siguientes métodos.
Portal
En la hoja de máquinas virtuales del portal, puede ver el botón de alternancia de la Ventaja híbrida de Azure para
Windows Server si selecciona la pestaña "Configuración".
PowerShell
En el ejemplo siguiente, se muestra el tipo de licencia de una sola máquina virtual
Get-AzVM -ResourceGroup "myResourceGroup" -Name "myVM"
Salida:
Type : Microsoft.Compute/virtualMachines
Location : westus
LicenseType : Windows_Server
Este resultado se contrasta con la siguiente máquina virtual implementada sin licencias para la ventaja para uso
híbrido de Azure para Windows Server:
Location : westus
LicenseType :
CLI
az vm get-instance-view -g MyResourceGroup -n MyVM --query "[?licenseType=='Windows_Server']" -o table

NOTE
Cuando se cambia el tipo de licencia de una máquina virtual, el sistema no se reinicia ni se interrumpe el servicio. Se trata
simplemente de una marca de licencia de metadatos.
Enumeración de todas las máquinas virtuales con la Ventaja híbrida de

Azure para Windows Server en una suscripción
Para ver y contar todas las máquinas virtuales implementadas con la ventaja para uso híbrido de Azure para
Windows Server, puede ejecutar el siguiente comando desde su suscripción:
Portal
En la hoja de recursos de la máquina virtual o de los conjuntos de escalado de máquinas virtuales, puede ver una
lista de todas las máquinas virtuales y el tipo de licencia si configura la columna de la tabla de forma que incluya
"Ventaja híbrida de Azure". El valor de la máquina virtual puede estar en los siguientes estados: "Habilitado", "No
habilitado" o "No compatible".
PowerShell
$vms = Get-AzVM
$vms | ?{$_.LicenseType -like "Windows_Server"} | select ResourceGroupName, Name, LicenseType
CLI
az vm list --query "[?licenseType=='Windows_Server']" -o table
Implementación de un conjunto de escalado de máquinas virtuales con

la Ventaja híbrida de Azure para Windows Server
En las plantillas de Resource Manager del conjunto de escalado de máquinas virtuales, se debe especificar un
parámetro licenseType adicional en la propiedad VirtualMachineProfile. Puede hacerlo durante la creación o
actualización del conjunto de escalado a través de la plantilla de ARM, PowerShell, la CLI de Azure o REST.
En el ejemplo siguiente, se usa una plantilla de ARM con una imagen de Windows Server 2016 Datacenter:
"virtualMachineProfile": {
"storageProfile": {
"osDisk": {
},
"imageReference": {
"sku": "2016-Datacenter",
"version": "latest"
}
},
"licenseType": "Windows_Server",
"osProfile": {
"computerNamePrefix": "[parameters('vmssName')]",
}
También puede obtener más información sobre cómo modificar un conjunto de escalado de máquinas virtuales
para conocer más formas de actualizar su conjunto de escalado.
Pasos siguientes
Obtenga más información sobre cómo ahorrar dinero con la Ventaja híbrida de Azure.
Obtenga más información sobre Preguntas más frecuentes sobre la Ventaja híbrida de Azure.
Aprenda más sobre la concesión de licencias para la Ventaja híbrida de Azure en esta guía detallada.
Obtenga más información sobre Azure Hybrid Benefit for Windows Server and Azure Site Recovery make
migrating applications to Azure even more cost-effective (la Ventaja híbrida de Azure para Windows Server y
Azure Site Recovery rentabilizan aún más la migración de aplicaciones a Azure).
Obtenga más información sobre Implementación de Windows 10 en Azure con derechos de hospedaje
multiinquilino.
Obtenga más información sobre el uso de plantillas de Resource Manager.
Implementación de Windows 10 en Azure con
derechos de hospedaje multiinquilino
Para los clientes con Windows 10 Enterprise E3/E5 por usuario o con acceso a escritorios virtuales de Windows
por usuario (licencias de suscripción de usuarios o licencias de suscripción de usuario de complemento), los
derechos de hospedaje multiinquilino de Windows 10 le permiten llevar sus licencias de Windows 10 a la nube y
ejecutar máquinas virtuales de Windows 10 en Azure sin pagar por otra licencia. Para más información, consulte
Multitenant Hosting for Windows 10 (Hospedaje multiinquilino para Windows 10).
NOTE
En este artículo se explica cómo implementar la ventaja de las licencias con las imágenes de Windows 10 Pro Desktop en
Azure Marketplace.
Para obtener las imágenes de Windows 7, 8.1 y 10 Enterprise (x64) en Azure Marketplace para suscripciones a MSDN,
consulte Uso del cliente Windows en Azure para escenarios de desarrollo y pruebas.
Para revisar las ventajas de licencias de Windows Server, consulte Ventaja para uso híbrido de Azure para Windows Server.
Implementación de la imagen de Windows 10 desde Azure

Marketplace
Para las implementaciones de plantilla de Powershell, CLI y Azure Resource Manager, la imagen de Windows 10
puede encontrarse con el siguiente nombre de editor, oferta o sku.
OS PUBLISHERNAME OFERTA SKU
Windows 10 Pro MicrosoftWindowsDesktop Windows-10 RS2-Pro
Windows 10 Pro N MicrosoftWindowsDesktop Windows-10 RS2-ProN
Windows 10 Pro MicrosoftWindowsDesktop Windows-10 RS3-Pro
Windows 10 Pro N MicrosoftWindowsDesktop Windows-10 RS3-ProN
Carga del disco duro virtual de Windows 10 en Azure

Si va a cargar un disco duro virtual generalizado de Windows 10, tenga en cuenta que Windows 10 no tiene una
cuenta de administrador integrada habilitada de forma predeterminada. Para habilitar la cuenta de administrador
integrada, incluya el siguiente comando como parte de la extensión de script personalizada.
Net user <username> /active:yes
El siguiente fragmento de código de PowerShell sirve para marcar todas las cuentas de administrador como
activas, incluida la del administrador integrado. Este ejemplo es útil si desconoce el nombre de usuario del
administrador integrado.
$adminAccount = Get-WmiObject Win32_UserAccount -filter "LocalAccount=True" | ? {$_.SID -Like "S-1-5-21-*-
500"}
if($adminAccount.Disabled)
{
$adminAccount.Disabled = $false
$adminAccount.Put()
}
Para obtener más información:

Carga del disco duro virtual en Azure
Preparación de un disco duro virtual de Windows para cargarlo en Azure
Implementación de Windows 10 con derechos de hospedaje

multiinquilino
Asegúrese de que tiene la versión de Azure PowerShell más reciente instalada y configurada. Cuando haya
preparado el disco duro virtual, cárguelo en su cuenta de Azure Storage mediante el cmdlet Add-AzVhd de la
siguiente forma:
Add-AzVhd -ResourceGroupName "myResourceGroup" -LocalFilePath "C:\Path\To\myvhd.vhd" `

-Destination "https://mystorageaccount.blob.core.windows.net/vhds/myvhd.vhd"
Implementación mediante la plantilla de Azure Resource Manager: dentro de las plantillas de Resource
Manager, se puede especificar un parámetro adicional para licenseType . En Creación de plantillas de Azure
Resource Manager, puede encontrar más información al respecto. Una vez que haya cargado el VHD en Azure,
edite la plantilla de Resource Manager para incluir el tipo de licencia como parte del proveedor de procesos e
impleméntela de la forma habitual:
"properties": {
"licenseType": "Windows_Client",
"vmSize": "[variables('vmSize')]"
}
Implementación mediante PowerShell: cuando se implementa una máquina virtual de Windows Server
mediante PowerShell, se dispone de un parámetro adicional para -LicenseType . Cuando el disco duro virtual esté
cargado en Azure, cree una máquina virtual mediante New-AzVM y especifique el tipo de concesión de licencias de
la siguiente forma:
New-AzVM -ResourceGroupName "myResourceGroup" -Location "West US" -VM $vm -LicenseType "Windows_Client"
Comprobación de que la máquina virtual está utilizando la ventaja de

licencia
Cuando haya implementado la máquina virtual mediante el método de implementación de Resource Manager o
PowerShell, compruebe el tipo de licencia con Get-AzVM , como se indica a continuación:
Get-AzVM -ResourceGroup "myResourceGroup" -Name "myVM"
La salida es similar a la del ejemplo siguiente para Windows 10 con el tipo correcto de licencia:
Location : westus
LicenseType : Windows_Client
Esta salida contrasta con la siguiente máquina virtual implementada sin la licencia de ventaja de uso híbrido de
Azure, como una implementada directamente desde la galería de Azure:
Location : westus
LicenseType :
Información adicional sobre la unión con Azure AD

NOTE
Azure aprovisiona todas las máquinas virtuales Windows con la cuenta de administrador integrada, que no se puede usar
para unirse con AAD. Por ejemplo, Configuración > Cuenta > Obtener acceso a trabajo o escuela > +Conectar no
funcionará. Debe crear e iniciar sesión como una segunda cuenta de administrador para unirse de forma manual a Azure AD.
También puede configurar Azure AD mediante un paquete de aprovisionamiento. Use el vínculo de la sección Pasos
siguientes para más información.
Pasos siguientes
Obtenga más información sobre la configuración de VDA para Windows 10.
Obtenga más información sobre el hospedaje multiinquilino para Windows 10
Recomendaciones de seguridad para las máquinas
virtuales de Windows en Azure
En este artículo se incluyen recomendaciones de seguridad para Azure Virtual Machines. Estas recomendaciones le
ayudarán a cumplir las obligaciones de seguridad descritas en nuestro modelo de responsabilidad compartida.
También le ayudarán a mejorar la seguridad general de las soluciones de aplicaciones web. Para más información
acerca de lo que hace Microsoft para cumplir sus responsabilidades como proveedor de servicios, consulte
Responsabilidades compartidas de la informática en la nube.
Algunas de las recomendaciones de este artículo se pueden seguir automáticamente mediante Azure Security
Center. Azure Security Center es la primera línea de defensa de los recursos de Azure. Se encarga de analizar el
estado de seguridad de los recursos de Azure para identificar posibles vulnerabilidades de seguridad. Y luego
ofrece recomendaciones para solucionar los puntos vulnerables. Para más información, consulte Recomendaciones
de seguridad de Azure Security Center.
Para más información sobre Azure Security Center, consulte ¿Qué es Azure Security Center?.
General
RECOMENDACIÓN COMENTARIOS SECURITY CENTER
Al crear imágenes de máquina virtual Antes de crear las imágenes, instale las -
personalizadas, aplique las actualizaciones más recientes tanto del
actualizaciones más recientes. sistema operativo como todas las
aplicaciones que formarán parte de la
imagen.
Mantener actualizadas las máquinas Puede usar la solución Update Sí

virtuales. Management de Azure Automation
para administrar las actualizaciones del
sistema operativo de los equipos
Windows y Linux en Azure.
Realice una copia de seguridad de las Azure Backup ayuda a proteger los -
máquinas virtuales. datos de las aplicaciones y tiene unos
costos operativos mínimos. Los errores
de una aplicación pueden dañar los
datos, y los errores humanos pueden
crear errores en las aplicaciones. Azure
Backup protege las máquinas virtuales
que ejecutan Windows y Linux.
Use varias máquinas virtuales para Si la máquina virtual ejecuta -

aumentar la resistencia y la aplicaciones que deben tener alta
disponibilidad. disponibilidad, usar varias máquinas
virtuales o conjuntos de disponibilidad.
Adopte una estrategia de continuidad Azure Site Recovery le permite elegir -

empresarial y recuperación ante entre diferentes opciones diseñadas
desastres (BCDR). para dar soporte a la continuidad
empresarial. Admite diferentes
escenarios de replicación y de
conmutación por error. Para más
información, consulte Acerca de Site
Recovery.
Seguridad de los datos

Cifre los discos del sistema operativo. Azure Disk Encryption le ayuda a cifrar Sí
los discos de máquina virtual IaaS de
Windows y Linux. Sin las claves
necesarias, el contenido de los discos
cifrado no se puede leer. El cifrado de
disco protege los datos almacenados
contra el acceso no autorizado que, de
lo contrario, sería posible si se copiara el
disco.
Cifre los discos de datos. Azure Disk Encryption le ayuda a cifrar -

los discos de máquina virtual IaaS de
Windows y Linux. Sin las claves
necesarias, el contenido de los discos
cifrado no se puede leer. El cifrado de
disco protege los datos almacenados
contra el acceso no autorizado que, de
lo contrario, sería posible si se copiara el
disco.
Limite el software instalado. Limite el software instalado al -

estrictamente necesario para aplicar
correctamente la solución. Esta guía
ayuda a reducir la superficie de la
solución expuesta a ataques.
Use antivirus o antimalware. En Azure, puede usar software -

antimalware de proveedores de
seguridad como Microsoft, Symantec,
Trend Micro y Kaspersky. Este software
ayudará a proteger las máquinas
virtuales contra archivos
malintencionados, adware y otras
amenazas. Puede implementar
Microsoft Antimalware en función de las
cargas de trabajo de las aplicaciones.
Use la configuración de seguridad
básica predeterminada o una
configuración personalizada avanzada.
Para más información, consulte
Microsoft Antimalware para Azure
Cloud Services y Virtual Machines.
Almacene de forma segura claves y Simplifique la administración de los -

secretos. secretos y claves proporcionando a los
propietarios de la aplicación una opción
segura administrada centralmente. Esta
administración reduce el riesgo de que
se produzca una pérdida o una
amenaza accidental. Azure Key Vault
puede almacenar de forma segura
claves en módulos de seguridad de
hardware (HSM) que tienen la
certificación FIPS 140-2 nivel 2. Si
necesita usar FIPs 140.2 nivel 3 para
almacenar las claves y secretos, puede
usar Azure Dedicated HSM.
Administración de identidades y acceso

Centralice la autenticación de máquinas Puede centralizar la autenticación de las -

virtuales. máquinas virtuales Windows y Linux
mediante la autenticación de
Azure Active Directory.
Supervisión
Supervise sus máquinas virtuales. Puede usar Azure Monitor para VM -

para supervisar el estado de las
máquinas virtuales y los conjuntos de
escalado de máquinas virtuales de
Azure. Los problemas de rendimiento
con una máquina virtual pueden
provocar la interrupción del servicio, lo
que infringe el principio de seguridad de
disponibilidad.
Redes
Restrinja del acceso a los puertos de Los atacantes analizan los intervalos de -
administración. direcciones IP de la nube pública en
busca de puertos de administración
abiertos e intentan realizar ataques
"sencillos", como contraseñas comunes
y puntos vulnerables conocidos sin
correcciones. Puede usar el acceso a
máquina virtual Just-In-Time (JIT) para
bloquear el tráfico entrante a las
máquinas virtuales de Azure, lo que
reduce la exposición a ataques y. al
mismo tiempo, se proporcionan
conexiones sencillas a las máquinas
virtuales cuando sean necesarias.
Límite el acceso a la red. Los grupos de seguridad de red le -

permiten restringir el acceso a la red y
controlar el número de puntos de
conexión expuestos. Para más
información, consulte Creación,
modificación o eliminación de un grupo
de seguridad de red .
Pasos siguientes
Póngase en contacto con el proveedor de la aplicación para obtener información acerca de otros requisitos de
seguridad. Para más información sobre el desarrollo de aplicaciones seguras, consulte Documentación sobre
desarrollo seguro.
Administración del acceso a máquina virtual mediante
Just-In-Time
El acceso a máquina virtual (VM ) Just-In-Time (JIT) se puede usar para bloquear el tráfico entrante a las máquinas virtuales
de Azure, lo que reduce la exposición a ataques y, al mismo tiempo, se proporciona acceso sencillo para conectarse a las
máquinas virtuales cuando sea necesario.
NOTE
La característica Just-In-Time está disponible en el nivel Estándar de Security Center. Para obtener más información sobre los planes de
tarifa de Security Center, vea Precios.
NOTE
Actualmente, el acceso a máquina virtual del tipo Just-In-Time de Security Center solo admite las máquinas virtuales implementadas a
través de Azure Resource Manager. Para obtener más información sobre los modelos de implementación clásico y de Resource Manager,
vea La implementación de Azure Resource Manager frente a la implementación clásica.
Escenario de ataque
Normalmente, los ataques por fuerza bruta tienen como destino los puertos de administración para obtener acceso a una
máquina virtual. Si un atacante tiene éxito, puede tomar el control de la máquina virtual y establecer un punto de apoyo en su
entorno.
Una manera de reducir el riesgo de sufrir un ataque por fuerza bruta consiste en limitar el tiempo que está abierto un puerto.
No es necesario que los puertos de administración estén abiertos en todo momento. Solo deben estar abiertos mientras se
está conectado a la máquina virtual, por ejemplo, para realizar tareas de administración o mantenimiento. Cuando se habilita
Just-In-Time, Security Center usa las reglas del grupo de seguridad de red (NSG ) y Azure Firewall, que restringen el acceso a
los puertos de administración para que no puedan ser objeto de ataques.
¿Cómo funciona el acceso JIT?

Cuando se habilita Just-In-Time, Security Center bloquea el tráfico entrante a las máquinas virtuales de Azure mediante la
creación de una regla de NSG. Se deben seleccionar los puertos de la máquina virtual para la que se bloqueará el tráfico
entrante. Estos puertos los controla la solución Just-In-Time.
Cuando un usuario solicita acceso a una máquina virtual, Security Center comprueba que el usuario tenga permisos de
control de acceso basado en rol (RBAC ) para la máquina virtual. Si la solicitud se aprueba, Security Center configura
automáticamente los grupos de seguridad de red (NSG ) y Azure Firewall para permitir el tráfico entrante a los puertos
seleccionados y a las direcciones o rangos IP de origen durante el periodo especificado. Una vez transcurrido ese tiempo,
Security Center restaura los NSG a su estado anterior. Pero las conexiones que ya están establecidas no se interrumpen.
NOTE
Si se aprueba una solicitud de acceso JIT para una VM detrás de una instancia de Azure Firewall, Security Center cambia
automáticamente las reglas de directiva de NSG y el firewall. Para la cantidad de tiempo que se especificó, las reglas permiten tráfico
entrante a los puertos seleccionados y las direcciones o rangos IP de origen solicitados. Una vez transcurrido el tiempo, Security Center
restaura las reglas del firewall y NSG a su estado anterior.
Permisos necesarios para configurar y usar JIT

PARA PERMITIR A LOS USUARIOS: PERMISOS QUE SE DEBEN ESTABLECER
Configurar o editar una directiva JIT para una VM Asigne estas acciones al rol.
En el ámbito de una suscripción o un grupo de recursos
asociados a la máquina virtual:
Microsoft.Security/locations/jitNetworkAccessPolicies/write
En el ámbito de una suscripción, un grupo de recursos o una
máquina virtual:
Microsoft.Compute/virtualMachines/write
Solicitud de acceso Just-In-Time a una máquina virtual Asigne estas acciones al usuario.
En el ámbito de una suscripción o un grupo de recursos
asociados a la máquina virtual:
Microsoft.Security/locations/jitNetworkAccessPolicies/initiate/action
En el ámbito de una suscripción, un grupo de recursos o una
máquina virtual:
Microsoft.Compute/virtualMachines/read
Configurar JIT en una VM

Existen tres maneras de configurar una directiva JIT en una máquina virtual:
Configurar el acceso JIT en Azure Security Center
Configurar el acceso JIT en una hoja de VM de Azure
Configurar una directiva JIT en una VM mediante programación
Configuración de JIT en Security Center

Desde Security Center, puede configurar un directiva de JIT y solicitar acceso a una VM mediante una directiva JIT.
Configuración del acceso JIT en una máquina virtual en Security Center
1. Abra el panel Security Center.
2. En el panel izquierdo, seleccione Just-in-time VM access (Acceso a máquina virtual del tipo Just-In-Time).
Se abre la ventana Just-in-time VM access (Acceso a máquina virtual del tipo Just-In-Time).
Just-in-time VM access (Acceso a máquina virtual del tipo Just-In-Time) proporciona información acerca del estado
de las máquinas virtuales:
Configurado: máquinas virtuales que se han configurado para admitir el acceso a máquina virtual Just-In-Time.
Los datos que se muestran son de la última semana e incluyen, para cada máquina virtual, el número de solicitudes
aprobadas, la fecha y hora del último acceso y el último usuario.
Recomendado: máquinas virtuales que pueden admitir el acceso a máquina virtual Just-In-Time, pero que no se
han configurado para ello. Se recomienda habilitar el control de acceso a máquina virtual Just-In-Time para estas
Ninguna recomendación: una máquina virtual podría no recomendarse por diversas razones:
Falta grupo de seguridad de red: la solución Just-In-Time requiere que exista un grupo de seguridad de red.
Máquina virtual clásica: en la actualidad, el acceso a máquina virtual Just-In-Time de Security Center solo
admite las máquinas virtuales implementadas mediante Azure Resource Manager. La solución Just-In-Time
no admite las implementaciones clásicas.
Otros: una VM se encuentra en esta categoría si la solución Just-In-Time está desactivada en la directiva de
seguridad de la suscripción o grupo de recursos, o si la VM no tiene una IP pública ni existe ningún grupo de
seguridad de red.
3. Seleccione la pestaña Recomendado.
4. En MÁQUINA VIRTUAL, haga clic en las VM que quiere habilitar. De este modo, se coloca una marca de verificación
junto a una máquina virtual.
5. Haga clic en Habilitar JIT en VM. -. Esta hoja muestran los puertos predeterminados que recomienda Azure Security
Center:
22 - SSH
3389 - RDP
5985 - WinRM
5986 - WinRM
6. También puede configurar puertos personalizados:
a. Haga clic en Agregar. Se abre la ventana Agregar configuración de puerto.
b. Para cada puerto que elija configurar, tanto el predeterminado como el configurado, puede personalizar los valores
siguientes:
Tipo de protocolo: el protocolo que se permite en este puerto cuando se aprueba una solicitud.
Direcciones IP de origen permitidas: los intervalos de IP que se permiten en este puerto cuando se aprueba una
solicitud.
Tiempo de solicitud máximo: el período de tiempo máximo durante el que puede estar abierto un puerto
específico.
c. Haga clic en OK.
7. Haga clic en Save(Guardar).
NOTE
Cuando el acceso a la VM JIT se habilita en una VM, Azure Security Center crea reglas para denegar todo el tráfico entrante para los
puertos seleccionados en los grupos de seguridad de red asociados y en Azure Firewall. Si no se habían creado otras reglas para los
puertos seleccionados, las reglas existentes tienen prioridad sobre las nuevas reglas para “denegar todo el tráfico entrante”. Si no hay
ninguna regla existente en los puertos seleccionados, las nuevas reglas de "denegar todo el tráfico entrante" tienen prioridad principal en
grupos de seguridad de red y Azure Firewall.
Solicitud de acceso JIT a través de Security Center

Para solicitar acceso a una VM a través de Security Center:
1. En Just in time VM access (Acceso a máquina virtual del tipo Just-In-Time), seleccione la pestaña Configurado.
2. En Máquina virtual, haga clic en las VM a las que quiera solicitar acceso. De este modo, se coloca una marca de
verificación junto a la VM.
El icono de la columna Detalles de la conexión indica si JIT está habilitado en el NSG o firewall. Si está
habilitado en ambos, solo aparece el icono de firewall.
En la columna Detalles de la conexión se proporciona la información necesaria para conectarse a la máquina
virtual y sus puertos abiertos.
3. Haga clic en Solicitar acceso. Se abre la ventana Solicitar acceso.
4. En Solicitar acceso, configure para cada máquina virtual los puertos que desee que se abran y las direcciones IP de
origen en que se abre el puerto y el tiempo durante el que permanecerá abierto. Solo se podrá solicitar acceso a los
puertos que estén configurados en la directiva Just-In-Time. Cada puerto tiene un tiempo máximo permitido que se
basa en la directiva Just-In-Time.
5. Haga clic en Abrir puertos.
NOTE
Si un usuario que solicita acceso está detrás de un proxy, es posible que la opción de Mi IP no funcione. Es posible que necesite definir
todo el intervalo de direcciones IP de la organización.
Edición de una directiva de acceso JIT a través de Security Center

Para cambiar la directiva Just-In-Time de una máquina virtual, agregue y configure un puerto nuevo que proteja dicha
máquina virtual, o bien cambie otro valor relacionado con un puerto ya protegido.
Para editar una directiva Just-In-Time existente de una máquina virtual:
1. En la ficha Configurado, en Máquinas virtuales, seleccione la máquina virtual a la que desea agregar un puerto.
Para ello, haga clic en los tres puntos situados en la fila de dicha máquina.
2. Seleccione Editar.
3. En Configuración de acceso a máquina virtual del tipo JIT , puede modificar la configuración existente de un
puerto protegido, o bien agregar un puerto personalizado.
Auditoría de la actividad de acceso JIT en Security Center

Puede usar la búsqueda de registros para obtener información sobre las actividades de las máquinas virtuales. Para ver los
registros:
1. En Just in time VM access (Acceso a máquina virtual del tipo Just-In-Time), seleccione la pestaña Configurado.
2. En VM, seleccione una máquina virtual sobre la que desee ver información, haga clic en las elipses situadas dentro de
la fila para esa VM y seleccione Registro de actividad en el menú. Se abre el registro de actividad.
En Registro de actividades se proporciona una vista filtrada de las operaciones anteriores para esa máquina virtual,
junto con el tiempo, la fecha y la suscripción.
Para descargar la información del registro, seleccione Haga clic aquí para descargar todos los elementos como archivo
.csv.
Modifique los filtros y haga clic en Aplicar para crear una búsqueda y un registro.
Configuración del acceso JIT desde la página de una máquina virtual de

Azure
Para su comodidad, puede conectarse a una máquina virtual con JIT directamente desde la página de la máquina virtual en
Security Center.
Configuración del acceso JIT en una máquina virtual a través de la página de la máquina virtual de Azure
Para facilitar el despliegue del acceso Just-In-Time en las VM, puede establecer una VM para permitir solo el acceso Just-In-
Time directamente desde dentro de la VM.
1. En Azure Portal, seleccione Máquinas virtuales.
2. Haga clic en la máquina virtual a la que quiere limitar el acceso Just-In-Time.
3. En el menú, haga clic en Configuración.
4. En Acceso Just-In-Time haga clic en Habilitar directiva Just-In-Time.
Esto habilita el acceso Just-In-Time para la VM con las siguientes opciones:
Servidores Windows:
Puerto RDP 3389
Se permite un tiempo de acceso máximo de tres horas
Las direcciones IP de origen permitidas se establecen en Cualquiera
Servidores Linux:
Puerto SSH 22
Se permite un tiempo de acceso máximo de tres horas
Las direcciones IP de origen permitidas se establecen en Cualquiera
Si una VM ya tiene Just-In-Time habilitado, cuando va a su página de configuración podrá ver que Just-In-Time está
habilitado y que puede usar el vínculo para abrir la directiva en Azure Security Center para ver y cambiar la configuración.
Solicitar acceso JIT a una VM a través de la hoja de VM de Azure

En Azure Portal, al intentar conectarse a una máquina virtual, Azure comprueba si hay alguna directiva de acceso Just-In-
Time configurada en ella.
Si tiene una directiva JIT configurada en la máquina virtual, puede hacer clic en Solicitar acceso para poder tener
acceso de acuerdo con la directiva JIT establecida para la máquina virtual.
Se solicita el acceso con los parámetros predeterminados siguientes:
source IP: "Cualquiera" (*) (no se puede modificar)
time range: Tres horas (o se puede modificar)
port number: puerto RDP 3389 para Windows; puerto 22 para Linux (se puede cambiar)
NOTE
Después de aprobarse una solicitud para una VM protegida con Azure Firewall, Security Center proporciona al usuario los
datos de conexión (asignación de puerto de la tabla DNAT) que debe usar para conectarse a la máquina virtual.
Si hay alguna máquina virtual en la que no esté configurado Just-In-Time, se le solicitará que la configure.
Configurar una directiva JIT en una VM mediante programación
Just-In-Time se puede configurar y usar tanto a través de las API REST como de PowerShell.
Acceso a la VM JIT a través de las API de REST

La característica de acceso a máquina virtual Just-in-Time se puede usar mediante la API de Azure Security Center. Use esta
API para obtener más información acerca de las máquinas virtuales configuradas, cómo agregar otras nuevas o solicitar
acceso a una máquina virtual, entre otras cosas. Consulte Jit Network Access Policies (Directivas de acceso a red JIT), para
más información acerca de la API REST Just-in-Time.
Acceso a la VM JIT mediante PowerShell

Para utilizar la solución de acceso a máquina virtual Just-In-Time mediante PowerShell, use los cmdlets de PowerShell de
Azure Security Center oficiales; específicamente Set-AzJitNetworkAccessPolicy .
En el siguiente ejemplo se establece una directiva de acceso a la máquina virtual del tipo Just-in-Time en una máquina virtual
específica, y se establece lo siguiente:
1. Cierre los puertos 22 y 3389.
2. Establezca una ventana de tiempo máximo de 3 horas para cada una, para que así puedan abrirse según la solicitud
aprobada.
3. Permite que el usuario que solicita el acceso controle las direcciones IP de origen; asimismo, le permite establecer una
sesión correcta tras una solicitud de acceso del tipo Just-In-Time aprobada.
Ejecute lo siguiente en PowerShell, para poder lograr lo que se ha detallado:
1. Asigne una variable que contenga la directiva de acceso a máquina virtual del tipo Just-in-Time para una máquina
virtual:
$JitPolicy = (@{
id="/subscriptions/SUBSCRIPTIONID/resourceGroups/RESOURCEGROUP/providers/Microsoft.Compute/virtualMachines/VMNAME
"
ports=(@{
number=22;
protocol="*";
allowedSourceAddressPrefix=@("*");
maxRequestAccessDuration="PT3H"},
@{
number=3389;
protocol="*";
allowedSourceAddressPrefix=@("*");
maxRequestAccessDuration="PT3H"})})
2. Inserte la directiva de acceso a máquina virtual del tipo Just-in-Time de la máquina virtual en una matriz:
$JitPolicyArr=@($JitPolicy)
3. Configure la directiva de acceso a máquina virtual del tipo Just-in-Time en la máquina virtual seleccionada:
Set-AzJitNetworkAccessPolicy -Kind "Basic" -Location "LOCATION" -Name "default" -ResourceGroupName "RESOURCEGROUP"

-VirtualMachine $JitPolicyArr
Solicitar acceso a una VM a través de PowerShell

En el siguiente ejemplo, puede ver una solicitud de acceso a máquina virtual del tipo Just-In-Time para una máquina virtual
específica, en la que se solicita que se abra el puerto 22 para una dirección IP específica y durante un período concreto:
Ejecute lo siguiente en PowerShell:
1. Configure las propiedades de acceso de solicitud de la máquina virtual.
$JitPolicyVm1 = (@{
id="/SUBSCRIPTIONID/resourceGroups/RESOURCEGROUP/providers/Microsoft.Compute/virtualMachines/VMNAME"
ports=(@{
number=22;
endTimeUtc="2018-09-17T17:00:00.3658798Z";
allowedSourceAddressPrefix=@("IPV4ADDRESS")})})
2. Inserte los parámetros de solicitud de acceso a la máquina virtual en una matriz:
$JitPolicyArr=@($JitPolicyVm1)
3. Envíe el acceso de solicitud (use el id. de recurso que obtuvo en el paso 1).
Start-AzJitNetworkAccessPolicy -ResourceId
"/subscriptions/SUBSCRIPTIONID/resourceGroups/RESOURCEGROUP/providers/Microsoft.Security/locations/LOCATION/jitNet
workAccessPolicies/default" -VirtualMachine $JitPolicyArr
Para obtener más información, consulte la documentación de cmdlet de PowerShell.
Pasos siguientes
En este artículo, ha aprendido la forma en que el acceso a máquina virtual del tipo Just-In-Time en Security Center ayuda a
controlar el acceso a máquinas virtuales de Azure.
Para más información sobre el Centro de seguridad, consulte los siguientes recursos:
Establecimiento de directivas de seguridad: aprenda a configurar directivas de seguridad para las suscripciones y los
grupos de recursos de Azure.
Administración de recomendaciones de seguridad: conozca una serie de recomendaciones que le ayudarán a proteger los
recursos de Azure.
Supervisión del estado de seguridad: obtenga información sobre cómo supervisar el mantenimiento de los recursos de
Azure.
Administración y respuesta a las alertas de seguridad: obtenga información sobre cómo administrar y responder a alertas
de seguridad.
Supervisión de las soluciones de asociados: aprenda a supervisar el estado de mantenimiento de las soluciones de
asociados.
Preguntas más frecuentes sobre Security Center: encuentre las preguntas más frecuentes sobre el uso del servicio.
Blog de seguridad de Azure : encuentre entradas de blog sobre el cumplimiento y la seguridad en Azure.
Escenarios de Azure Disk Encryption en máquinas
virtuales Windows
Azure Disk Encryption usa el protector de claves externas BitLocker para proporcionar cifrado de volumen tanto a
los discos de datos como a los del sistema operativo de máquinas virtuales de Azure, y se integra con Azure Key
Vault para ayudarle a controlar y administrar las claves y los secretos del cifrado de disco. Para obtener
información general del servicio, consulte Azure Disk Encryption para máquinas virtuales Windows.
Hay muchos escenarios de cifrado de disco y los pasos pueden variar en función del escenario. En las secciones
siguientes se tratan con más detalle los escenarios de máquinas virtuales Windows.
El cifrado de disco solo se puede aplicar a las máquinas virtuales que tengan tamaños y sistemas operativos
compatibles. También es preciso que se cumplan los siguientes requisitos previos:
Requisitos de red
IMPORTANT
VM. Para más información, consulte Azure Disk Encryption con Azure AD (versión anterior).
Es preciso hacer una instantánea o crear una copia de seguridad antes de cifrar los discos. Las copias de seguridad
garantizan que, en caso de un error inesperado durante el cifrado, sea posible una opción de recuperación. Las
máquinas virtuales con discos administrados requieren una copia de seguridad antes del cifrado. Una vez realizada la
copia de seguridad, puede usar el cmdlet Set-AzVMDiskEncryptionExtension para cifrar los discos administrados
mediante la especificación del parámetro -skipVmBackup. Para más información sobre cómo realizar la copia de
seguridad y la restauración de máquinas virtuales cifradas, consulte Copia de seguridad y restauración de máquinas
virtuales de Azure cifradas.
Cifrar o deshabilitar el cifrado puede provocar el reinicio de una máquina virtual.
Instalación de herramientas y conexión a Azure

Azure Disk Encryption se puede habilitar y administrar mediante la CLI de Azure y Azure PowerShell. Para ello, es
preciso instalar las herramientas localmente y conectarse a la suscripción de Azure.
CLI de Azure
La CLI de Azure 2.0 es una herramienta de línea de comandos para administrar recursos de Azure. La CLI está
diseñada para flexibilizar los datos de consulta, admitir operaciones de larga duración (como los procesos sin
bloqueo) y facilitar la realización de scripts. Para instalarla localmente, siga los pasos que puede encontrar en
Instalación de la CLI de Azure.
Para iniciar sesión en su cuenta de Azure con la CLI de Azure, use el comando az login.
az login
Si quiere seleccionar un inquilino con el que iniciar sesión, use:

az login --tenant <tenant>
Si tiene varias suscripciones y quiere especificar una en concreto, use az account list para obtener la lista de
suscripciones y az account set para especificar cuál.
az account list
az account set --subscription "<subscription name or ID>"
Para más información, consulte Service Fabric y CLI de Azure 2.0.

Azure PowerShell
El módulo az de Azure PowerShell ofrece un conjunto de cmdlets que usan el modelo de Azure Resource
Manager para administrar los recursos de Azure. Se puede usar en el explorador con Azure Cloud Shell, o bien se
puede instalar en una máquina local, para lo que hay que seguir las instrucciones de Instalación del módulo de
Azure PowerShell.
Si ya lo tiene instalado localmente, asegúrese de que usa la versión más reciente de la versión del SDK de Azure
PowerShell para configurar Azure Disk Encryption. Descargue la versión más reciente de Azure PowerShell.
Para iniciar sesión en una cuenta de Azure con Azure PowerShell, utilice el cmdlet Connect-AzAccount.
Connect-AzAccount
Si tiene varias suscripciones y desea especificar una de ellas, use el cmdlet Get-AzSubscription para enumerarlas
y, después, el cmdlet Set-AzContext:
Set-AzContext -Subscription -Subscription <SubscriptionId>
La ejecución del cmdlet Get-AzContext verificará que se ha seleccionado la suscripción correcta.

Para confirmar que están instalados los cmdlets de Azure Disk Encryption, use el cmdlet Get-command:
Get-command *diskencryption*
Para más información, consulte Introducción a los cmdlets de Azure PowerShell.
Habilitación del cifrado en una máquina virtual Windows existente o en

ejecución
En este escenario, puede habilitar el cifrado mediante la plantilla de Resource Manager, los cmdlets de PowerShell
o los comandos de la CLI. Si necesita información de esquema para la extensión de máquina virtual, consulte el
artículo sobre la extensión de Azure Disk Encryption para Windows.
Habilitación del cifrado en máquinas virtuales IaaS de Windows

existentes o en ejecución
Puede habilitar el cifrado mediante una plantilla, los cmdlets de PowerShell o los comandos de la CLI. Si necesita
información de esquema para la extensión de máquina virtual, consulte el artículo sobre la extensión de Azure
Disk Encryption para Windows.
Habilitación del cifrado en máquinas virtuales existentes o en ejecución con Azure PowerShell
Use el cmdlet Set-AzVMDiskEncryptionExtension para habilitar el cifrado en una máquina virtual IaaS en
ejecución en Azure.
Cifrado de una máquina virtual en ejecución: el siguiente script inicializa las variables y ejecuta el
cmdlet Set-AzVMDiskEncryptionExtension. Ya se deben haber satisfecho los requisitos previos de crear el
grupo de recursos, la máquina virtual y el almacén de claves. Reemplace MyKeyVaultResourceGroup,
MyVirtualMachineResourceGroup, MySecureVM y MySecureVault por los valores deseados.
$KVRGname = 'MyKeyVaultResourceGroup';
$VMRGName = 'MyVirtualMachineResourceGroup';
$vmName = 'MySecureVM';
$KeyVaultName = 'MySecureVault';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGname -VMName $vmName -

DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -DiskEncryptionKeyVaultId $KeyVaultResourceId;
Cifrado de una máquina virtual en ejecución mediante KEK:
$vmName = 'MyExtraSecureVM';
$keyEncryptionKeyName = 'MyKeyEncryptionKey';
$keyEncryptionKeyUrl = (Get-AzKeyVaultKey -VaultName $KeyVaultName -Name
$keyEncryptionKeyName).Key.kid;
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGname -VMName $vmName -DiskEncryptionKeyVaultUrl

$diskEncryptionKeyVaultUrl -DiskEncryptionKeyVaultId $KeyVaultResourceId -KeyEncryptionKeyUrl
$keyEncryptionKeyUrl -KeyEncryptionKeyVaultId $KeyVaultResourceId;
NOTE
La sintaxis del valor del parámetro disk-encryption-keyvault es la cadena completa del identificador:
/subscriptions/[subscription-id-guid]/resourceGroups/[resource-group-
name]/providers/Microsoft.KeyVault/vaults/[keyvault-name]
La sintaxis del valor del parámetro key-encryption-key es el URI completo de KEK como en: https://[keyvault-
name].vault.azure.net/keys/[kekname]/[kek-unique-id]
Comprobar que los discos están cifrados: para comprobar el estado de cifrado de una máquina virtual
de IaaS, use el cmdlet Get-AzVmDiskEncryptionStatus.
Get-AzVmDiskEncryptionStatus -ResourceGroupName 'MyVirtualMachineResourceGroup' -VMName 'MySecureVM'
Deshabilitar el cifrado de disco: para deshabilitar el cifrado, use el cmdlet Disable-AzVMDiskEncryption.

La deshabilitación del cifrado de disco de datos en la VM de Windows cuando se han cifrado tanto los
discos de datos como del SO no funciona según lo previsto. Deshabilite del cifrado en todos los discos en
su lugar.
Disable-AzVMDiskEncryption -ResourceGroupName 'MyVirtualMachineResourceGroup' -VMName 'MySecureVM'
Habilitación del cifrado en máquinas virtuales existentes o en ejecución con la CLI de Azure
Use el comando az vm encryption enable para habilitar el cifrado en una máquina virtual IaaS en ejecución en
Azure.
Cifrado de una máquina virtual en ejecución:
az vm encryption enable --resource-group "MyVirtualMachineResourceGroup" --name "MySecureVM" --disk-

encryption-keyvault "MySecureVault" --volume-type [All|OS|Data]

encryption-keyvault "MySecureVault" --key-encryption-key "MyKEK_URI" --key-encryption-keyvault
"MySecureVaultContainingTheKEK" --volume-type [All|OS|Data]
NOTE
IaaS, use el comando az vm encryption show.
az vm encryption show --name "MySecureVM" --resource-group "MyVirtualMachineResourceGroup"
Deshabilitar el cifrado: para deshabilitar el cifrado, use el comando az vm encryption disable. La

deshabilitación del cifrado de disco de datos en la VM de Windows cuando se han cifrado tanto los discos
de datos como del SO no funciona según lo previsto. Deshabilite del cifrado en todos los discos en su lugar.
az vm encryption disable --name "MySecureVM" --resource-group "MyVirtualMachineResourceGroup" --volume-

type [ALL, DATA, OS]
Uso de la plantilla de Resource Manager

Puede habilitar el cifrado de disco en máquinas virtuales IaaS de Windows existentes o en ejecución en Azure
mediante la plantilla de Resource Manager para cifrar una máquina virtual Windows en ejecución.
1. En la plantilla de inicio rápido de Azure, haga clic en Deploy to Azure (Implementar en Azure).
2. Seleccione la suscripción, el grupo de recursos, la ubicación, la configuración, los términos legales y el
contrato. Haga clic en Comprar para habilitar el cifrado en la máquina virtual IaaS existente o en ejecución.
En la tabla siguiente figuran los parámetros de la plantilla de Resource Manager para máquinas virtuales
existentes o en ejecución:
PARÁMETRO DESCRIPCIÓN
vmName Nombre de la máquina virtual para ejecutar la operación de

cifrado.
keyVaultName Nombre del almacén de claves en el que se que debe cargar la

clave de BitLocker. Puede obtenerlo mediante el cmdlet
(Get-AzKeyVault -ResourceGroupName
<MyKeyVaultResourceGroupName>). Vaultname
o el comando de la CLI de Azure
az keyvault list --resource-group
"MyKeyVaultResourceGroup"
keyVaultResourceGroup Nombre del grupo de recursos que contiene el almacén de

claves
keyEncryptionKeyURL La dirección URL de la clave de cifrado de claves con el

formato
https://<nombreDelAlmacénDeClaves>.vault.azure.net/key/<
nombreDeClave>. Si no desea usar una KEK, deje este campo
en blanco.
volumeType Tipo de volumen en que se realiza la operación de cifrado. Los

valores válidos son SO, Datos y Todo.
forceUpdateTag Cada vez que la operación tenga que ejecutarse, pase un valor
único como GUID.
resizeOSDisk Si se debería cambiar el tamaño de la partición del sistema

operativo para ocupar el VHD del sistema operativo completo
antes de dividir el volumen del sistema.
location Ubicación para todos los recursos.
Máquinas virtuales IaaS creadas a partir de discos duros virtuales

cifrados por el cliente y claves de cifrado
En este escenario, puede crear una máquina virtual a partir de un disco duro virtual previamente cifrado y las
claves de cifrado asociadas mediante cmdlets de PowerShell o comandos de la CLI.
Siga las instrucciones que encontrará en Preparación de un disco duro virtual previamente cifrado. Una vez
creada la imagen, puede seguir los pasos de la sección siguiente para crear una VM cifrada de Azure.
Cifrado de máquinas virtuales con discos duros virtuales previamente cifrados con Azure PowerShell
Puede habilitar el cifrado de disco en el disco duro virtual cifrado mediante el cmdlet Set-AzVMOSDisk de
PowerShell. En el ejemplo siguiente se proporcionan algunos parámetros comunes.
$VirtualMachine = New-AzVMConfig -VMName "MySecureVM" -VMSize "Standard_A1"

$VirtualMachine = Set-AzVMOSDisk -VM $VirtualMachine -Name "SecureOSDisk" -VhdUri "os.vhd" Caching ReadWrite -
Windows -CreateOption "Attach" -DiskEncryptionKeyUrl
"https://mytestvault.vault.azure.net/secrets/Test1/514ceb769c984379a7e0230bddaaaaaa" -DiskEncryptionKeyVaultId
"/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myKVresourcegroup/providers/Microsoft.KeyVault/vaults/mytestvault"
New-AzVM -VM $VirtualMachine -ResourceGroupName "MyVirtualMachineResourceGroup"
Habilitación del cifrado en un disco de datos recién agregado

También puede agregar un nuevo disco a una máquina virtual Windows con PowerShell o mediante Azure Portal.
Habilitación del cifrado en un disco recién agregado con Azure PowerShell
Al usar PowerShell para cifrar un nuevo disco para máquinas virtuales Windows, se debe especificar una nueva
versión de secuencia. La versión de secuencia debe ser única. El siguiente script genera un GUID para la versión
de secuencia. En algunos casos, un disco de datos recién agregado se podría cifrar automáticamente mediante la
extensión Azure Disk Encryption. El cifrado automático suele producirse cuando se reinicia la máquina virtual
después de que el nuevo disco se pone en línea. Esto se suele producir porque se especificó "All" para el tipo de
volumen cuando el cifrado de disco se ejecutó anteriormente en la máquina virtual. Si el cifrado automático se
produce en un disco de datos recién agregado, se recomienda volver a ejecutar el cmdlet Set-
AzVmDiskEncryptionExtension con la nueva versión de secuencia. Si el nuevo disco de datos es de cifrado
automático y no desea cifrarlo, descifre todas las unidades en primer lugar y, a continuación, vuelva a cifrarlas con
una nueva versión de secuencia que especifique el sistema operativo para el tipo de volumen.
Cifrado de una máquina virtual en ejecución: el siguiente script inicializa las variables y ejecuta el
cmdlet Set-AzVMDiskEncryptionExtension. Ya se deben haber satisfecho los requisitos previos de crear el
grupo de recursos, la máquina virtual y el almacén de claves. Reemplace MyKeyVaultResourceGroup,
MyVirtualMachineResourceGroup, MySecureVM y MySecureVault por los valores deseados. Este ejemplo
utiliza "All" para el parámetro -VolumeType, que incluye los volúmenes de sistema operativo y de datos. Si
solo quiere cifrar el volumen del sistema operativo, use "OS" para el parámetro VolumeType.
$sequenceVersion = [Guid]::NewGuid();
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGname -VMName $vmName -

DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -DiskEncryptionKeyVaultId $KeyVaultResourceId -
VolumeType "All" –SequenceVersion $sequenceVersion;
Cifrado de una máquina virtual en ejecución mediante KEK: Este ejemplo utiliza "All" para el
parámetro -VolumeType, que incluye los volúmenes de sistema operativo y de datos. Si solo quiere cifrar el
volumen del sistema operativo, use "OS" para el parámetro VolumeType.
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGname -VMName $vmName -DiskEncryptionKeyVaultUrl

$diskEncryptionKeyVaultUrl -DiskEncryptionKeyVaultId $KeyVaultResourceId -KeyEncryptionKeyUrl
$keyEncryptionKeyUrl -KeyEncryptionKeyVaultId $KeyVaultResourceId -VolumeType "All" –SequenceVersion
$sequenceVersion;
NOTE
Habilitación del cifrado en un disco recién agregado con la CLI de Azure

El comando de la CLI de Azure proporciona automáticamente una nueva versión de secuencia al ejecutarlo para
habilitar el cifrado. El ejemplo usa "All" para el parámetro VolumeType. Es posible que deba cambiar el parámetro
VolumeType para el sistema operativo si solo está cifrando el disco del sistema operativo. A diferencia de la
sintaxis de PowerShell, la CLI no requiere que el usuario proporcione ninguna versión de secuencia única cuando
se habilita el cifrado. La CLI genera y usa su propio valor de versión de secuencia único automáticamente.
Cifrado de una máquina virtual en ejecución:

encryption-keyvault "MySecureVault" --volume-type "All"

encryption-keyvault "MySecureVault" --key-encryption-key "MyKEK_URI" --key-encryption-keyvault
"MySecureVaultContainingTheKEK" --volume-type "All"
Deshabilitación del cifrado

Puede deshabilitar el cifrado con Azure PowerShell, la CLI de Azure o una plantilla de Resource Manager. La
deshabilitación del cifrado de disco de datos en la VM de Windows cuando se han cifrado tanto los discos de
datos como del SO no funciona según lo previsto. Deshabilite del cifrado en todos los discos en su lugar.
Deshabilitar el cifrado de disco con Azure PowerShell: para deshabilitar el cifrado, use el cmdlet
Disable-AzVMDiskEncryption.
Disable-AzVMDiskEncryption -ResourceGroupName 'MyVirtualMachineResourceGroup' -VMName 'MySecureVM' -

VolumeType "all"
Deshabilitar el cifrado con la CLI de Azure: para deshabilitar el cifrado, use el comando az vm
encryption disable.
az vm encryption disable --name "MySecureVM" --resource-group "MyVirtualMachineResourceGroup" --volume-

type "all"
Deshabilitar el cifrado con una plantilla de Resource Manager:

1. Haga clic en Deploy to Azure (Implementar en Azure) en la plantilla Deshabilitar el cifrado de disco en
una máquina virtual Windows en ejecución.
2. Seleccione la suscripción, el grupo de recursos, la ubicación, la máquina virtual, el tipo de volumen, los
términos legales y el contrato.
3. Haga clic en Comprar para deshabilitar el cifrado de disco en una máquina virtual Windows en
ejecución.
Escenarios no admitidos
Azure Disk Encryption no funciona para los siguientes escenarios, características ni tecnologías:
VM de cifrado de nivel básico o VM creadas a través del método de creación de VM clásico.
VM de cifrado configuradas con sistemas RAID basados en software.
VM de cifrado configuradas con espacios de almacenamiento directo (S2D ), o bien versiones de Windows
Server anteriores a 2016 configuradas con espacios de almacenamiento de Windows.
Integración con un sistema de administración de claves local.
Azure Files (sistema de archivos compartido).
Network File System (NFS ).
Volúmenes dinámicos.
Contenedores de Windows Server, que crean volúmenes dinámicos para cada contenedor.
Discos de sistema operativo efímero.
Cifrado de sistemas de archivos compartidos o distribuidos como DFS, GFS, DRDB, and CephFS (sin limitarse
solo a estos).
Pasos siguientes
Introducción a Azure Disk Encryption
Scripts de ejemplo de Azure Disk Encryption
Solución de problemas de Azure Disk Encryption
Inicio rápido: Creación y cifrado de una máquina
virtual Windows con la CLI de Azure
La CLI de Azure se usa para crear y administrar recursos de Azure desde la línea de comandos o en scripts. Este
inicio rápido muestra cómo usar la CLI de Azure para crear y cifrar una máquina virtual con
Windows Server 2016.
Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno
local.
Para iniciar Azure Cloud Shell:
OPCIÓN EJEMPLO O VÍNCULO
Seleccione Probarlo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Probar no se copia
automáticamente el código en Cloud Shell.
Vaya a https://shell.azure.com o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.
Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.
Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell; para ello, seleccione Ctrl+Shift+V en Windows y Linux, o
bien seleccione Cmd+Shift+V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar la CLI en un entorno local, en esta guía de inicio rápido es preciso que ejecute la versión
2.0.30 de la CLI de Azure o una posterior. Ejecute az --version para encontrar la versión. Si necesita instalarla o
actualizarla, vea Instalación de la CLI de Azure.

Cree un grupo de recursos con el comando az group create. Un grupo de recursos de Azure es un contenedor
lógico en el que se implementan y se administran los recursos de Azure. En el ejemplo siguiente, se crea un grupo
de recursos denominado myResourceGroup en la ubicación eastus:

Cree la máquina virtual con az vm create. En el ejemplo siguiente se crea una máquina virtual denominada
myVM. En este ejemplo se utiliza azureuser como nombre de usuario administrativo y myPassword12 como
contraseña.
az vm create \
--name myVM \
--admin-password myPassword12
La creación de la máquina virtual y los recursos auxiliares tarda unos minutos en realizarse. En la salida de
ejemplo siguiente se muestra que la operación de creación de la máquina virtual se realizó correctamente.
{
"fqdns": "",
"id":
"/subscriptions/<guid>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM",
"location": "eastus",
"macAddress": "00-0D-3A-23-9A-49",
"powerState": "VM running",
"publicIpAddress": "52.174.34.95",
"resourceGroup": "myResourceGroup"
}
Creación de una instancia de Key Vault configurada para claves de

cifrado
Azure Disk Encryption almacena su clave de cifrado en una instancia de Azure Key Vault. Cree una instancia de
Key Vault con az keyvault create. Para habilitar la instancia de Key Vault para almacenar claves de cifrado, use el
parámetro --enabled-for-disk-encryption.
IMPORTANT
Cada instancia de Key Vault debe tener un nombre único. En el siguiente ejemplo se crea una instancia de Key Vault llamada
myKV, pero debe llamar a la suya de forma diferente.
az keyvault create --name "myKV" --resource-group "myResourceGroup" --location eastus --enabled-for-disk-

encryption
Cifrado de la máquina virtual

Cifre su máquina virtual con az vm encryption, que proporciona su nombre de Key Vault único al parámetro --
disk-encryption-keyvault.
az vm encryption enable -g MyResourceGroup --name MyVM --disk-encryption-keyvault myKV

Puede comprobar que el cifrado está habilitado en su máquina virtual con az vm show
az vm show --name MyVM -g MyResourceGroup
Verá lo siguiente en la salida devuelta:
"EncryptionOperation": "EnableEncryption"
Cuando ya no los necesite, puede usar el comando az group delete para quitar el grupo de recursos, la máquina
virtual y Key Vault.
Pasos siguientes
En este inicio rápido, creó una máquina virtual y una instancia de Key Vault que se habilitó para claves de cifrado,
y cifró la máquina virtual. En el artículo siguiente obtendrá más información acerca de los requisitos previos de
Azure Disk Encryption para máquinas virtuales IaaS.
virtual Windows en Azure con PowerShell
El módulo de Azure PowerShell se usa para crear y administrar recursos de Azure desde la línea de comandos de
PowerShell o en scripts. En esta guía de inicio rápido se le muestra cómo usar el módulo de Azure PowerShell
para crear una máquina virtual (VM ) Windows, crear una instancia de Key Vault para el almacenamiento de claves
de cifrado y cifrar la máquina virtual.

en el que se implementan y administran los recursos de Azure.
New-AzResourceGroup -Name "myResourceGroup" -Location "EastUS"

Cree una máquina virtual de Azure con New -AzVM. Debe suministrar las credenciales al cmdlet.
New-AzVM -Name MyVm -Credential $cred -ResourceGroupName MyResourceGroup -Image win2016datacenter -Size
Standard_D2S_V3
La implementación de la máquina virtual tardará unos minutos.
Creación de una instancia de Key Vault configurada para claves de

cifrado
Azure Disk Encryption almacena su clave de cifrado en una instancia de Azure Key Vault. Cree una instancia de
Key Vault con New -AzKeyvault. Para habilitar la instancia de Key Vault para almacenar claves de cifrado, use el
parámetro -EnabledForDiskEncryption.
IMPORTANT
Cada instancia de Key Vault debe tener un nombre único. En el siguiente ejemplo se crea una instancia de Key Vault llamada
myKV, pero debe llamar a la suya de forma diferente.
New-AzKeyvault -name MyKV -ResourceGroupName myResourceGroup -Location EastUS -EnabledForDiskEncryption

Cifre su máquina virtual con Set-AzVmDiskEncryptionExtension.
Set-AzVmDiskEncryptionExtension requiere algunos valores de su objeto de Key Vault. Puede obtener estos
valores pasando el nombre único de su almacén de claves a Get-AzKeyvault.
$KeyVault = Get-AzKeyVault -VaultName MyKV -ResourceGroupName MyResourceGroup
Set-AzVMDiskEncryptionExtension -ResourceGroupName MyResourceGroup -VMName MyVM -DiskEncryptionKeyVaultUrl

$KeyVault.VaultUri -DiskEncryptionKeyVaultId $KeyVault.ResourceId
Después de unos minutos, el proceso devolverá el siguiente resultado:
RequestId IsSuccessStatusCode StatusCode ReasonPhrase

--------- ------------------- ---------- ------------
True OK OK
Puede comprobar el proceso de cifrado ejecutando Get-AzVmDiskEncryptionStatus.
Get-AzVmDiskEncryptionStatus -VMName MyVM -ResourceGroupName MyResourceGroup
Al habilitarse el cifrado, verá lo siguiente en la salida que se devuelve:
OsVolumeEncrypted : Encrypted
DataVolumesEncrypted : NoDiskFound
OsVolumeEncryptionSettings : Microsoft.Azure.Management.Compute.Models.DiskEncryptionSettings
ProgressMessage : Provisioning succeeded
Cuando ya no se necesiten, puede usar el cmdlet Remove-AzResourceGroup para quitar el grupo de recursos, la
VM y todos los recursos relacionados:
Remove-AzResourceGroup -Name "myResourceGroup"
Pasos siguientes
En este inicio rápido, creó una máquina virtual y una instancia de Key Vault que se habilitó para claves de cifrado,
y cifró la máquina virtual. En el artículo siguiente obtendrá más información acerca de los requisitos previos de
Azure Disk Encryption para máquinas virtuales IaaS.
virtual Windows desde Azure Portal
Las máquinas virtuales de Azure pueden crearse mediante Azure Portal. Azure Portal es una interfaz de usuario
basada en explorador para crear máquinas virtuales y recursos asociados. En este inicio rápido se usará Azure
Portal para implementar una máquina virtual Windows que usa Ubuntu 18.04 LTS, crear un almacén de claves
para las claves de cifrado y cifrar la máquina virtual.

Inicie sesión en el Azure Portal.
Creación de un Almacén de claves

1. Seleccione la opción Crear un recurso de la esquina superior izquierda de Azure Portal.
2. En el cuadro de búsqueda, escriba Key Vault.
3. En la lista de resultados, seleccione Key Vault.
4. En la sección Key Vault, seleccione Crear.
5. En la pantalla Crear almacén de claves, elija un nombre único para el nuevo almacén de claves.
IMPORTANT
Cada instancia de Key Vault debe tener un nombre único. En el siguiente ejemplo se crea una instancia de Key Vault
llamada myADEKV, pero debe llamar a la suya de otra forma.
6. Seleccione una suscripción.

7. En Grupo de recursos, seleccione Crear nuevo. En el menú emergente, escriba myResourceGroup para el
nombre del grupo de recursos y luego elija Aceptar.
8. En el menú desplegable Ubicación, elija Este de EE. UU.

9. Deje las restantes opciones con sus valores predeterminados.
10. Seleccione "Directivas de acceso", lo que le llevará a una nueva pantalla.
11. Active la casilla que esta junto a "Habilitar el acceso a Azure Disk Encryption para el cifrado de volúmenes".
12. En la parte inferior de la pantalla de directivas de acceso, haga clic en "Revisar y crear".
13. Después de revisar, haga clic en "Crear".
1. Elija Crear un recurso en la esquina superior izquierda de Azure Portal.
2. En la página Nuevo, en Popular, seleccione Windows Server 2016 Datacenter.
3. En la pestaña Datos básicos, en Detalles del proyecto, asegúrese de que está seleccionada la suscripción
correcta.
4. En Grupo de recursos, seleccione el grupo de recursos que creó al preparar el almacén de claves (p.ej.,
myResourceGroup).
5. En Nombre de máquina virtual , escriba MyVM.
6. En Región, seleccione la misma región que usó al crear el almacén de claves (p.ej., Este de EE. UU. ).
7. Asegúrese de que el valor de Tamaño es Estándar D2s v3.
8. En Cuenta de administrador , seleccione Contraseña. Escriba un nombre de usuario y una contraseña.
9. Seleccione la pestaña "Administración" y compruebe que tiene una cuenta de almacenamiento de
diagnóstico. Si no tiene cuentas de almacenamiento, seleccione "Crear nuevo", asigne un nombre a la cuenta
nueva y seleccione "Aceptar"
10. Haga clic en "Revisar y crear".

11. En la página Crear una máquina virtual verá los detalles de la máquina virtual que va a crear. Cuando esté
preparado, seleccione Crear.
La implementación de la máquina virtual tardará unos minutos. Cuando finalice la implementación, pase a la
siguiente sección.

1. Cuando la implementación de la máquina virtual se complete, seleccione Ir al recurso.
2. En la barra lateral izquierda, seleccione Discos.
3. En la pantalla Discos, seleccione Cifrado.
4. En la pantalla de cifrado, en Disks to encrypt (Discos que se cifran), elija OS and data disks (Discos de SO
y de datos).
5. En Configuración de cifrado, haga clic en "Seleccionar un almacén de claves y una clave para el cifrado".
6. En la barra lateral derecha, seleccione el nombre del almacén de claves que creó anteriormente como valor
de Almacén de claves y haga clic en Seleccionar.
7. En la parte superior de la pantalla de cifrado, haga clic en "Guardar". Un elemento emergente le avisará que
la máquina virtual se va a reiniciar la máquina virtual. Haga clic en Sí.
relacionados. Para ello, seleccione el grupo de recursos de la máquina virtual, seleccione Eliminar y confirme el
nombre del grupo de recursos que desea eliminar.
Pasos siguientes
En este inicio rápido ha creado un almacén de claves que se ha habilitado para las claves de cifrado, ha creado una
máquina virtual y ha habilitado la máquina virtual para el cifrado.
Creación y configuración de un almacén de claves
para Azure Disk Encryption
Azure Disk Encryption usa Azure Key Vault para controlar y administrar las claves y los secretos de cifrado de
discos. Para más información sobre los almacenes de claves, consulte Introducción a Azure Key Vault y
Protección de un almacén de claves.
WARNING
VM. Para más información, consulte Creación y configuración de un almacén de claves para Azure Disk Encryption con
Azure AD (versión anterior).
La creación y configuración de un almacén de claves para su uso con Azure Disk Encryption conlleva estos tres
pasos:
1. Creación de un grupo de recursos, en caso de que sea necesario.
2. Creación de un almacén de claves.
3. Establecimiento de directivas de acceso avanzadas del almacén de claves.
Estos pasos se muestran en los siguientes tutoriales de inicio rápido:
Creación y cifrado de una máquina virtual Windows con la CLI de Azure
Creación y cifrado de una máquina virtual Windows con Azure PowerShell
Si lo desea, también puede generar o importar una clave de cifrado de claves (KEK).
NOTE
Los pasos que se describen en este artículo se automatizan en el script de la CLI de requisitos previos de Azure Disk
Encryption y en el script de PowerShell de requisitos previos de Azure Disk Encryption.
Instalación de herramientas y conexión a Azure

Los pasos que se describen en este artículo se pueden completar con la CLI de Azure, el módulo Az de Azure
PowerShell o Azure Portal.
Aunque se puede acceder al portal a través de un explorador, tanto la CLI de Azure como Azure PowerShell
requieren una instalación local; consulte Azure Disk Encryption para Windows: instalación de herramientas para
más información.
Conexión a la cuenta de Azure
Antes de usar la CLI de Azure o Azure PowerShell, es preciso conectarse a su suscripción de Azure. Para ello,
inicie sesión con la CLI de Azure, inicie sesión con Azure Powershell o escriba sus credenciales en Azure Portal
cuando se le soliciten.
az login
Connect-AzAccount

Si ya tiene un grupo de recursos, puede pasar a Creación de un almacén de claves.
Un grupo de recursos es un contenedor lógico en el que se implementan y se administran los recursos de
Azure.
Cree un grupo de recursos mediante el comando az group create de la CLI de Azure, el comando New -
AzResourceGroup de Azure PowerShell o bien desde Azure Portal.
CLI de Azure
az group create --name "myResourceGroup" --location eastus
Azure PowerShell

Si ya tiene un almacén de claves, puede pasar a la sección Establecimiento de directivas de acceso avanzadas
del almacén de claves.
Cree un almacén de claves mediante el comando az keyvault create de la CLI de Azure, el comando New -
AzKeyvault de Azure Powershell, Azure Portal o una plantilla de Resource Manager.
WARNING
Para asegurarse de que los secretos de cifrado no traspasan los límites regionales, Azure Disk Encryption requiere que Key
Vault y las máquinas virtuales se encuentren en la misma región. Cree y use un almacén de claves que se encuentre en la
misma región que las máquinas virtuales que se van a cifrar.
Cada instancia de Key Vault debe tener un nombre único. Reemplace <nombre-almacén de claves-único> por
el nombre del almacén de claves en los ejemplos siguientes.
CLI de Azure
Al crear un almacén de claves mediante la CLI de Azure, agregue la marca "--enabled-for-disk-encryption".
az keyvault create --name "<your-unique-keyvault-name>" --resource-group "myResourceGroup" --location

"eastus" --enabled-for-disk-encryption
Azure PowerShell
Al crear un almacén de claves mediante Azure PowerShell, agregue la marca "-EnabledForDiskEncryption".
New-AzKeyvault -name "<your-unique-keyvault-name>" -ResourceGroupName "myResourceGroup" -Location "eastus"

-EnabledForDiskEncryption

También puede crear un almacén de claves mediante la plantilla de Resource Manager.
2. Seleccione la suscripción, el grupo de recursos, la ubicación del grupo de recursos, el nombre del almacén de
claves, el identificador de objeto, los términos legales y el contrato, y luego haga clic en Comprar.
Establecimiento de directivas de acceso avanzadas del almacén de

claves
La plataforma Azure necesita acceso a las claves de cifrado o secretos del almacén de claves para ponerlos a
disposición de la máquina virtual para el proceso de arranque y descifrado de los volúmenes.
Si no ha habilitado el almacén de claves para el cifrado de discos, la implementación o la implementación de
plantillas en el momento de la creación (como se muestra en el paso anterior), debe actualizar sus directivas de
acceso avanzadas.
CLI de Azure
Use az keyvault update para habilitar el cifrado de disco para el almacén de claves.
Habilitar Key Vault para el cifrado de disco: Es necesario Enabled-for-disk-encryption.
az keyvault update --name "<your-unique-keyvault-name>" --resource-group "MyResourceGroup" --enabled-

for-disk-encryption "true"
Habilitar Key Vault para la implementación, si es necesario: permite que el proveedor de recursos
Microsoft.Compute recupere los secretos de este almacén de claves cuando se hace referencia al
almacén de claves en la creación de recursos, por ejemplo, cuando se crea una máquina virtual.

for-deployment "true"
Habilitar Key Vault para la implementación de plantillas, si es necesario: permite que Resource
Manager recupere secretos del almacén.

for-template-deployment "true"
Azure PowerShell
Use el cmdlet Set-AzKeyVaultAccessPolicy de PowerShell del almacén de claves para habilitar el cifrado de
disco para el almacén de claves.
Habilitar Key Vault para el cifrado de disco: se requiere EnabledForDiskEncryption para el cifrado de
Azure Disk.
Set-AzKeyVaultAccessPolicy -VaultName "<your-unique-keyvault-name>" -ResourceGroupName

"MyResourceGroup" -EnabledForDiskEncryption
Microsoft.Compute recupere los secretos de este almacén de claves cuando se hace referencia al
almacén de claves en la creación de recursos, por ejemplo, cuando se crea una máquina virtual.

"MyResourceGroup" -EnabledForDeployment
Habilitar Key Vault para la implementación de plantillas, si es necesario: permite que Azure
Resource Manager obtenga los secretos de este almacén de claves cuando se hace referencia al almacén
de claves en una implementación de plantilla.

"MyResourceGroup" -EnabledForTemplateDeployment
Portal de Azure
1. Seleccione el almacén de claves, vaya a Directivas de acceso y haga clic para mostrar las directivas
de acceso avanzadas.
2. Active la casilla etiquetada Habilitar el acceso a Azure Disk Encryption para el cifrado de
volúmenes.
3. Seleccione Habilitar el acceso a Azure Virtual Machines para la implementación o Habilitar el
acceso a Azure Resource Manager para la implementación de plantillas, si es necesario.
Configuración de una clave de cifrado de claves (KEK)

Si desea usar una clave de cifrado de claves (KEK) para una brindar una capa adicional de seguridad para las
claves de cifrado, agregue una KEK a su almacén de claves. Cuando se especifica una clave de cifrado de claves,
Azure Disk Encryption usa esa clave para encapsular los secretos de cifrado antes de escribirlos en Key Vault.
Puede generar una nueva clave de cifrado de claves mediante el comando az keyvault key create de la CLI de
Azure, el cmdlet Add-AzKeyVaultKey de Azure PowerShell o Azure Portal. Debe generar un tipo de clave RSA;
Azure Disk Encryption no admite aún el uso de claves de curva elíptica.
En su lugar, puede importar una clave de cifrado de claves en el HSM de administración de claves local. Para
más información, consulte la documentación de Key Vault.
Las direcciones URL de la KEK del almacén de claves deben tener versiones. Azure exige esta restricción del
control de versiones. Para ver direcciones URL de KEK y de secretos válidas, vea los ejemplos siguientes:
Ejemplo de dirección URL de secreto válida:
https://contosovault.vault.azure.net/secrets/EncryptionSecretWithKek/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Ejemplo de dirección URL de clave de cifrado de claves válida:
https://contosovault.vault.azure.net/keys/diskencryptionkek/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Azure Disk Encryption no admite la especificación de números de puerto como parte de los secretos del
almacén de claves y las direcciones URL de KEK. Para ver ejemplos de direcciones URL de almacén de claves
admitidas y no admitidas, consulte los siguientes:
Dirección URL de almacén de claves aceptable:
https://contosovault.vault.azure.net/secrets/contososecret/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dirección URL de almacén de claves inaceptable
https://contosovault.vault.azure.net:443/secrets/contososecret/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
CLI de Azure
Use el comando az keyvault key create de la CLI de Azure para generar una clave de cifrado de claves y
almacenarla en el almacén de claves.
az keyvault key create --name "myKEK" --vault-name "<your-unique-keyvault-name>" --kty RSA-HSM
En su lugar, puede importar una clave privada mediante el comando az keyvault key import de la CLI de Azure:
En cualquier caso, especificará el nombre de la clave de cifrado de claves al parámetro --key-encryption-key del
comando az vm encryption enable de la CLI de Azure.
az vm encryption enable -g "MyResourceGroup" --name "myVM" --disk-encryption-keyvault "<your-unique-

keyvault-name>" --key-encryption-key "myKEK"
Azure PowerShell
Use el cmdlet Add-AzKeyVaultKey de Azure PowerShell para generar una clave de cifrado de claves y
almacenarla en el almacén de claves.
Add-AzKeyVaultKey -Name "myKEK" -VaultName "<your-unique-keyvault-name>" -Destination "HSM"
En su lugar, puede importar una clave privada mediante el comando az keyvault key import de Azure
PowerShell.
En cualquier caso, especificará tanto el identificador del almacén de claves de la clave de cifrado de claves como
la dirección URL de la clave de cifrado de claves en los parámetros Set-AzVMDiskEncryptionExtension -
KeyEncryptionKeyVaultId y -KeyEncryptionKeyUrl de Azure PowerShell. Tenga en cuenta que en este ejemplo se
asume que se usa el mismo almacén de claves para la clave de cifrado de discos y la clave de cifrado de claves.
$KeyVault = Get-AzKeyVault -VaultName "<your-unique-keyvault-name>" -ResourceGroupName "myResourceGroup"

$KEK = Get-AzKeyVaultKey -VaultName "<your-unique-keyvault-name>" -Name "myKEK"
Set-AzVMDiskEncryptionExtension -ResourceGroupName MyResourceGroup -VMName "MyVM" -

DiskEncryptionKeyVaultUrl $KeyVault.VaultUri -DiskEncryptionKeyVaultId $KeyVault.ResourceId -
KeyEncryptionKeyVaultId $KeyVault.ResourceId -KeyEncryptionKeyUrl $KEK.Id -SkipVmBackup -VolumeType All
Pasos siguientes
Información acerca de los escenarios de Azure Disk Encryption en máquinas virtuales Windows
Aprenda a solucionar los problemas de Azure Disk Encryption
Lea los scripts de ejemplo de Azure Disk Encryption
Scripts de ejemplo de Azure Disk Encryption
En este artículo se proporcionan scripts de ejemplo tanto para preparar los discos duros virtuales previamente
cifrados como para realizar otras tareas.
Enumeración de máquinas virtuales y secretos

Enumeración de todas las máquinas virtuales cifradas de una suscripción:
$osVolEncrypted = {(Get-AzVMDiskEncryptionStatus -ResourceGroupName $_.ResourceGroupName -VMName

$_.Name).OsVolumeEncrypted}
$dataVolEncrypted= {(Get-AzVMDiskEncryptionStatus -ResourceGroupName $_.ResourceGroupName -VMName
$_.Name).DataVolumesEncrypted}
Get-AzVm | Format-Table @{Label="MachineName"; Expression={$_.Name}}, @{Label="OsVolumeEncrypted";
Expression=$osVolEncrypted}, @{Label="DataVolumesEncrypted"; Expression=$dataVolEncrypted}
Enumeración de todos los secretos de cifrado de disco usados para cifrar las máquinas virtuales de un almacén de
claves:
Get-AzKeyVaultSecret -VaultName $KeyVaultName | where {$_.Tags.ContainsKey('DiskEncryptionKeyFileName')} |

format-table @{Label="MachineName"; Expression={$_.Tags['MachineName']}}, @{Label="VolumeLetter"; Expression=
{$_.Tags['VolumeLetter']}}, @{Label="EncryptionKeyURL"; Expression={$_.Id}}
Scripts de requisitos previos de Azure Disk Encryption

Si ya está familiarizado con los requisitos previos para Azure Disk Encryption, puede usar el script de PowerShell
de requisitos previos de Azure Disk Encryption. Para un ejemplo de uso de este script de PowerShell, consulte la
guía de inicio rápido para el cifrado de máquinas virtuales. Puede quitar los comentarios de una sección del script,
a partir de la línea 211, para cifrar todos los discos de las máquinas virtuales de un grupo de recursos existente.
En la siguiente tabla se muestran los parámetros que se pueden usar en el script de PowerShell:
PARÁMETRO DESCRIPCIÓN ¿OBLIGATORIO?
$resourceGroupName Nombre del grupo de recursos al que True

pertenece la instancia de KeyVault. Si no
existe, se creará un grupo de recursos
con este nombre.
$keyVaultName Nombre de la instancia de KeyVault en True

donde se colocarán las claves de
cifrado. Si no existe, se creará un
almacén con este nombre.
$location Ubicación de la instancia de KeyVault. True

Asegúrese de que la instancia de
KeyVault y las máquinas virtuales que
se van a cifrar están en la misma
ubicación. Obtenga una lista de
ubicaciones con Get-AzLocation .
PARÁMETRO DESCRIPCIÓN ¿OBLIGATORIO?
$subscriptionId Identificador de la suscripción de Azure True

que se va a utilizar. El identificador de la
suscripción se puede obtener con
Get-AzSubscription .
$aadAppName Nombre de la aplicación de Azure AD False

que se va a utilizar para escribir
secretos en KeyVault. Si no existe, se
creará una aplicación con este nombre.
Si esta aplicación ya existe, pasará el
parámetro aadClientSecret al script.
$aadClientSecret Secreto de cliente de la aplicación de False

Azure AD que se creó anteriormente.
$keyEncryptionKeyName Nombre de la clave de cifrado de clave False

opcional en KeyVault. Si no existe, se
creará una clave con este nombre.
Plantillas de Resource Manager

Cifrado o descifrado de máquinas virtuales sin aplicación de Azure AD
Habilitación del cifrado de disco en una máquina virtual Windows existente o en ejecución
Deshabilitación del cifrado en una máquina virtual Windows en ejecución
Cifrado o descifrado de máquinas virtuales con aplicación de Azure AD (versión anterior)
Habilitación del cifrado de disco en una máquina virtual Windows existente o en ejecución
Deshabilitación del cifrado en una máquina virtual Windows en ejecución
Crear un disco administrado cifrado a partir de un blob de almacenamiento o disco duro virtual previamente
cifrado
Crea un disco administrado cifrado a partir de un disco duro virtual previamente cifrado y su
correspondiente configuración de cifrado.
Preparación de un VHD con Windows precifrado

Las secciones siguientes son necesarias para preparar un VHD con Windows precifrado para implementarlo como
VHD cifrado en IaaS de Azure. Utilice la información para preparar y arrancar una máquina virtual (VHD ) con
Windows nueva en Azure Site Recovery o Azure. Para más información sobre cómo preparar y cargar un disco
duro virtual, consulte Carga de un VHD generalizado y su uso para crear máquinas virtuales nuevas en Azure.
Actualización de una directiva de grupo para permitir un módulo no TPM para la protección del sistema
operativo
Configure la opción de la directiva de grupos de BitLocker denominada Cifrado de unidad BitLocker, que se
encuentra en Directiva de equipo local > Configuración del equipo > Plantillas administrativas >
Componentes de Windows. Cambie esta opción a: Unidades del sistema operativo > Requerir
autenticación adicional al iniciar > Permitir BitLocker sin un TPM compatible, como se muestra en la
ilustración siguiente:
Instalación de componentes de características de BitLocker
Para Windows Server 2012 y versiones posteriores, utilice el siguiente comando:
dism /online /Enable-Feature /all /FeatureName:BitLocker /quiet /norestart
Para Windows Server 2008 R2, utilice el siguiente comando:
ServerManagerCmd -install BitLockers
Preparación del volumen del sistema operativo para BitLocker mediante bdehdcfg
Si es necesario, ejecute el comando bdehdcfg para comprimir la partición del sistema operativo y preparar la
máquina para BitLocker:
bdehdcfg -target c: shrink -quiet
Protección del volumen del sistema operativo mediante BitLocker

Use el comando manage-bde para habilitar el cifrado en el volumen de arranque mediante un protector de clave
externo. También puede colocar la clave externa (archivo .bek) en el disco externo o el volumen. El cifrado se
habilita en el volumen de sistema o de arranque la próxima vez que se reinicie el equipo.
manage-bde -on %systemdrive% -sk [ExternalDriveOrVolume]

reboot
NOTE
Prepare la máquina virtual con un VHD de datos o recursos separado para obtener la clave externa mediante BitLocker.
Carga de un VHD cifrado a una cuenta de almacenamiento de Azure
Una vez que se cifre DM -Crypt, el disco duro virtual cifrado local debe cargarse en la cuenta de almacenamiento.
Add-AzVhd [-Destination] <Uri> [-LocalFilePath] <FileInfo> [[-NumberOfUploaderThreads] <Int32> ] [[-

BaseImageUriToPatch] <Uri> ] [[-OverWrite]] [ <CommonParameters>]
Carga del secreto de la máquina virtual previamente cifrada en el

almacén de claves
El secreto de cifrado del disco que obtuvo con anterioridad se debe cargar como un secreto en el almacén de
claves. Para ello, es preciso conceder el permiso para establecer secretos como el permiso para encapsular claves a
la cuenta que cargará los secretos.
# Typically, account Id is the user principal name (in user@domain.com format)

$upn = (Get-AzureRmContext).Account.Id
Set-AzKeyVaultAccessPolicy -VaultName $kvname -UserPrincipalName $acctid -PermissionsToKeys wrapKey -
PermissionsToSecrets set
# In cloud shell, the account ID is a managed service identity, so specify the username directly
# $upn = "user@domain.com"
# Set-AzKeyVaultAccessPolicy -VaultName $kvname -UserPrincipalName $acctid -PermissionsToKeys wrapKey -
PermissionsToSecrets set
# When running as a service principal, retrieve the service principal ID from the account ID, and set access
policy to that
# $acctid = (Get-AzureRmContext).Account.Id
# $spoid = (Get-AzureRmADServicePrincipal -ServicePrincipalName $acctid).Id
# Set-AzKeyVaultAccessPolicy -VaultName $kvname -ObjectId $spoid -BypassObjectIdValidation -PermissionsToKeys
wrapKey -PermissionsToSecrets set
Secreto del cifrado de disco no cifrado con una KEK

Para configurar el secreto en el almacén de claves, use Set-AzKeyVaultSecret. La frase de contraseña se codifica en
forma de cadena base64 y, después, se carga en el almacén de claves. Además, asegúrese de que se establecen las
siguientes etiquetas al crear el secreto en el almacén de claves.
# This is the passphrase that was provided for encryption during the distribution installation
$passphrase = "contoso-password"
$tags = @{"DiskEncryptionKeyEncryptionAlgorithm" = "RSA-OAEP"; "DiskEncryptionKeyFileName" =

"LinuxPassPhraseFileName"}
$secretName = [guid]::NewGuid().ToString()
$secretValue = [Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($passphrase))
$secureSecretValue = ConvertTo-SecureString $secretValue -AsPlainText -Force
$secret = Set-AzKeyVaultSecret -VaultName $KeyVaultName -Name $secretName -SecretValue $secureSecretValue -

tags $tags
$secretUrl = $secret.Id
Use $secretUrl en el paso siguiente para conectar el disco del sistema operativo sin usar KEK.
Secreto del cifrado de disco cifrado con una KEK
Antes de cargar el secreto en el almacén de claves, puede cifrarlo si lo desea mediante una clave de cifrado de
claves. Utilice la API de encapsulamiento para cifrar por primera vez el secreto mediante la clave de cifrado de
claves. El resultado de esta operación de encapsulamiento es una cadena codificada en URL como base64 que
luego se carga como secreto con el cmdlet Set-AzKeyVaultSecret .
# This is the passphrase that was provided for encryption during the distribution installation
$passphrase = "contoso-password"
Add-AzKeyVaultKey -VaultName $KeyVaultName -Name "keyencryptionkey" -Destination Software

$KeyEncryptionKey = Get-AzKeyVaultKey -VaultName $KeyVault.OriginalVault.Name -Name "keyencryptionkey"
$apiversion = "2015-06-01"
##############################
# Get Auth URI
##############################
$uri = $KeyVault.VaultUri + "/keys"

$headers = @{}
$response = try { Invoke-RestMethod -Method GET -Uri $uri -Headers $headers } catch {
$_.Exception.Response }
$authHeader = $response.Headers["www-authenticate"]
$authUri = [regex]::match($authHeader, 'authorization="(.*?)"').Groups[1].Value
Write-Host "Got Auth URI successfully"
##############################
# Get Auth Token
##############################
$uri = $authUri + "/oauth2/token"

$body = "grant_type=client_credentials"
$body += "&client_id=" + $AadClientId
$body += "&client_secret=" + [Uri]::EscapeDataString($AadClientSecret)
$body += "&resource=" + [Uri]::EscapeDataString("https://vault.azure.net")
$headers = @{}
$response = Invoke-RestMethod -Method POST -Uri $uri -Headers $headers -Body $body
$access_token = $response.access_token
Write-Host "Got Auth Token successfully"
##############################
# Get KEK info
##############################
$uri = $KeyEncryptionKey.Id + "?api-version=" + $apiversion

$headers = @{"Authorization" = "Bearer " + $access_token}
$response = Invoke-RestMethod -Method GET -Uri $uri -Headers $headers
$keyid = $response.key.kid
Write-Host "Got KEK info successfully"
##############################
# Encrypt passphrase using KEK
##############################
$passphraseB64 = [Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($Passphrase))
$uri = $keyid + "/encrypt?api-version=" + $apiversion
$headers = @{"Authorization" = "Bearer " + $access_token; "Content-Type" = "application/json"}
$bodyObj = @{"alg" = "RSA-OAEP"; "value" = $passphraseB64}
$body = $bodyObj | ConvertTo-Json
$response = Invoke-RestMethod -Method POST -Uri $uri -Headers $headers -Body $body
$wrappedSecret = $response.value
$wrappedSecret = $response.value
Write-Host "Encrypted passphrase successfully"
##############################
# Store secret
##############################
$secretName = [guid]::NewGuid().ToString()
$uri = $KeyVault.VaultUri + "/secrets/" + $secretName + "?api-version=" + $apiversion
$secretAttributes = @{"enabled" = $true}
$secretTags = @{"DiskEncryptionKeyEncryptionAlgorithm" = "RSA-OAEP"; "DiskEncryptionKeyFileName" =
"LinuxPassPhraseFileName"}
$headers = @{"Authorization" = "Bearer " + $access_token; "Content-Type" = "application/json"}
$bodyObj = @{"value" = $wrappedSecret; "attributes" = $secretAttributes; "tags" = $secretTags}
$body = $bodyObj | ConvertTo-Json
$response = Invoke-RestMethod -Method PUT -Uri $uri -Headers $headers -Body $body
Write-Host "Stored secret successfully"
$secretUrl = $response.id
Use $KeyEncryptionKey y $secretUrl en el paso siguiente para conectar el disco del sistema operativo usando
KEK.
Especificación de una dirección URL de secreto al adjuntar un disco del

sistema operativo
Sin utilizar una KEK
Mientras esté adjuntando el disco del sistema operativo, tiene que pasar $secretUrl . La dirección URL se generó
en la sección "Secreto de cifrado de disco no cifrado con una KEK".
Set-AzVMOSDisk `
-VM $VirtualMachine `
-Name $OSDiskName `
-SourceImageUri $VhdUri `
-VhdUri $OSDiskUri `
-Windows `
-CreateOption FromImage `
-DiskEncryptionKeyVaultId $KeyVault.ResourceId `
-DiskEncryptionKeyUrl $SecretUrl
Uso de una KEK

Cuando conecte un disco del sistema operativo, pase $KeyEncryptionKey y $secretUrl . La dirección URL se
generó en la sección "Secreto del cifrado de disco cifrado con KEK".
Set-AzVMOSDisk `
-VM $VirtualMachine `
-Name $OSDiskName `
-SourceImageUri $CopiedTemplateBlobUri `
-VhdUri $OSDiskUri `
-Windows `
-CreateOption FromImage `
-DiskEncryptionKeyVaultId $KeyVault.ResourceId `
-DiskEncryptionKeyUrl $SecretUrl `
-KeyEncryptionKeyVaultId $KeyVault.ResourceId `
-KeyEncryptionKeyURL $KeyEncryptionKey.Id
Guía de solución de problemas de Azure Disk
Encryption
Esta guía está destinada a profesionales de tecnologías de la información (TI), analistas de seguridad de la
información y administradores de la nube cuyas organizaciones utilizan Azure Disk Encryption. En este artículo se
ofrece ayuda para solucionar problemas relacionados con el cifrado de disco.
Antes de realizar cualquiera de los pasos siguientes, asegúrese de que las máquinas virtuales que intenta cifrar
tienen tamaños y sistemas operativos admitidos y que ha cumplido todos los requisitos previos:
Requisitos de red
Solución de problemas de Azure Disk Encryption detrás de un firewall

Cuando la conectividad está limitada por un firewall, la configuración del grupo de seguridad de red (NSG ) o el
requisito de proxy, podría perderse la capacidad de la extensión para realizar las tareas necesarias. Esto puede dar
lugar a mensajes de estado similares a "El estado de extensión no está disponible en la máquina virtual". En los
escenarios esperados, el cifrado no puede finalizar. En las secciones siguientes se enumeran algunos problemas
comunes del firewall que podría investigar.
Parte de la configuración del grupo de seguridad de red que se aplica debe permitir todavía que el punto de
conexión cumpla con los requisitos previos documentados de la configuración de red para el cifrado del disco.
Azure Key Vault detrás de un firewall
Cuando se está habilitando el cifrado con credenciales de Azure AD, la máquina virtual de destino debe permitir la
conectividad a los puntos de conexión de Azure Active Directory y Key Vault. Los puntos de conexión de
autenticación actuales de Azure Active Directory se mantienen en las secciones 56 y 59 de la documentación
sobre los intervalos de direcciones IP y direcciones URL de Office 365. En la documentación sobre cómo acceder
a Azure Key Vault detrás de un firewall se proporcionan instrucciones de Key Vault.
Servicio de metadatos de instancia de Azure
La máquina virtual debe poder acceder al punto de conexión de Azure Instance Metadata Service que utiliza una
dirección IP no enrutable conocida ( 169.254.169.254 ) a la que solo se puede acceder desde la máquina virtual. No
se admiten las configuraciones de proxy que modifican el tráfico HTTP local hacia esta dirección (por ejemplo,
agregando un encabezado X-Forwarded-For).
Solución de problemas de Windows Server 2016 Server Core

En Windows Server 2016 Server Core, el componente bdehdcfg no está disponible de forma predeterminada. y
Azure Disk Encryption necesita dicho componente. Se utiliza para dividir el volumen del sistema del volumen del
sistema operativo, lo que se realiza una única vez en toda la duración de la máquina virtual. Estos archivos
binarios no son necesarios durante las operaciones de cifrado posteriores.
Para solucionar este problema, copie los cuatro archivos siguientes de una máquina virtual del centro de datos de
Windows Server 2016 en la misma ubicación de Server Core:
\windows\system32\bdehdcfg.exe
\windows\system32\bdehdcfglib.dll
\windows\system32\en-US\bdehdcfglib.dll.mui
\windows\system32\en-US\bdehdcfg.exe.mui
1. Escriba el comando siguiente:
bdehdcfg.exe -target default
2. Este comando crea una partición de sistema de 550 MB. Reinicie el sistema.
3. Use DiskPart para comprobar los volúmenes y, a continuación, siga.
Por ejemplo:
DISKPART> list vol
Volume ### Ltr Label Fs Type Size Status Info

---------- --- ----------- ----- ---------- ------- --------- --------
Volume 0 C NTFS Partition 126 GB Healthy Boot
Volume 1 NTFS Partition 550 MB Healthy System
Volume 2 D Temporary S NTFS Partition 13 GB Healthy Pagefile
Solución de problemas de estado del cifrado

Es posible que el portal muestre que un disco está cifrado incluso después de haberse descifrado en la máquina
virtual. Esto puede ocurrir cuando se usan comandos de nivel inferior para descifrar directamente el disco de la
máquina virtual, en lugar de usar los comandos de administración de Azure Disk Encryption de nivel superior. Los
comandos del nivel superior no solo descifran el disco de la máquina virtual, sino fuera de la máquina virtual
también actualizan configuración importante de cifrado de nivel de plataforma y configuración de extensión
asociada con la máquina virtual. Si estos no se mantienen en la alineación, la plataforma no podrá informar del
estado de cifrado ni aprovisionar la máquina virtual correctamente.
Para deshabilitar Azure Disk Encryption con PowerShell, use Disable-AzVMDiskEncryption seguido de Remove-
AzVMDiskEncryptionExtension. Si se ejecuta Remove-AzVMDiskEncryptionExtension antes de deshabilitar el
cifrado, se producirá un error.
Para deshabilitar Azure Disk Encryption con la CLI, use az vm encryption disable.
Pasos siguientes
En este documento, aprendió más acerca de algunos problemas comunes de Azure Disk Encryption y cómo
solucionarlos. Para más información acerca de este servicio y su funcionalidad, consulte los artículos siguientes:
Aplicación de cifrado de discos en Azure Security Center
Cifrado de datos en reposo de Azure
Preguntas frecuentes acerca de Azure Disk Encryption
En este artículo se ofrecen respuestas a las preguntas más frecuentes sobre Azure Disk Encryption para máquinas
virtuales Windows. Para más información sobre este servicio, consulte Introducción a Azure Disk Encryption.
¿Dónde está Azure Disk Encryption en la disponibilidad general (GA)?

Azure Disk Encryption tiene disponibilidad general en todas las regiones públicas de Azure.
¿Qué experiencias del usuario están disponibles con Azure Disk

Encryption?
La disponibilidad general de Azure Disk Encryption admite plantillas de Azure Resource Manager, Azure
PowerShell y CLI de Azure. La diferentes experiencias de usuario le proporcionan flexibilidad. Dispone de tres
opciones distintas para habilitar el cifrado de discos para las máquinas virtuales. Para más información sobre la
experiencia del usuario e instrucciones paso a paso disponibles en Azure Disk Encryption, consulte Escenarios de
Azure Disk Encryption para Windows.
¿Cuánto cuesta Azure Disk Encryption?

El cifrado de discos de máquinas virtuales con Azure Disk Encryption es gratuito, pero hay cargos asociados al uso
de Azure Key Vault. Para más información acerca de los costos de Azure Key Vault, consulte la página de precios de
Key Vault.
¿Cómo puedo empezar a usar Azure Disk Encryption?

Para empezar, lea la información general sobre Azure Disk Encryption.
¿Qué tamaños de máquina virtual y sistemas operativos admiten Azure

Disk Encryption?
En el artículo Introducción a Azure Disk Encryption se enumeran los tamaños de máquina virtual y los sistemas
operativos de máquina virtual compatibles con Azure Disk Encryption.
¿Puedo cifrar los volúmenes de datos y arranque con Azure Disk

Encryption?
Puede cifrar tanto el volumen de arranque como el de datos, pero no puede cifrar el de datos sin cifrar antes el del
sistema operativo.
Una vez que se haya cifrado el volumen del sistema operativo no se admite la deshabilitación del cifrado en dicho
volumen.
¿Puedo cifrar un volumen desmontado con Azure Disk Encryption?

No. Azure Disk Encryption solo cifra volúmenes montados.
¿Cómo se pueden rotar los secretos o las claves de cifrado?
Para rotar los secretos, simplemente llame al mismo comando que usó originalmente para habilitar el cifrado de
disco y especifique un almacén de claves diferente. Para rotar la clave de cifrado de claves, llame al mismo
comando que usó originalmente para habilitar el cifrado de disco y especifique el cifrado de claves nuevo.
WARNING
Si usó anteriormente Azure Disk Encryption con la aplicación Azure AD para al especificar las credenciales de Azure AD
para cifrar esta VM, tendrá que seguir usando esta opción para cifrar la VM. Azure Disk Encryption no se puede usar en
esta máquina virtual cifrada, ya que no es un escenario compatible, lo que significa que el cambio desde la aplicación de
AAD a esta máquina virtual cifrada aún no es compatible.
¿Cómo se agrega o quita una clave de cifrado de clave si originalmente

no usé una?
Para agregar una clave de cifrado de clave, llame al comando enable otra vez y pase el parámetro de clave de
cifrado de clave. Para quitar una clave de cifrado de clave, llame al comando enable otra vez y pase el parámetro de
clave de cifrado de clave.
¿Permite Azure Disk Encryption habilitar la funcionalidad "traiga su

propia clave" (BYOK)?
Sí, puede proporcionar sus propias claves de cifrado de claves. Dichas claves están protegidas en Azure Key Vault,
que es el almacén de claves de Azure Disk Encryption. Para más información sobre los escenarios de
compatibilidad de las claves de cifrado de claves, consulte Creación y configuración de un almacén de claves para
¿Puedo usar una clave de cifrado de claves creada en Azure?

Sí, puede usar Azure Key Vault para generar la clave de cifrado de claves para usar en Azure Disk Encryption.
Dichas claves están protegidas en Azure Key Vault, que es el almacén de claves de Azure Disk Encryption. Para más
información sobre la clave de cifrado de claves, consulte Creación y configuración de un almacén de claves para
¿Puedo usar el servicio de administración de claves local o HSM para

proteger las claves de cifrado?
No puede utilizar el servicio de administración de claves local ni HSM para proteger las claves de cifrado con
Azure Disk Encryption. Para proteger las claves de cifrado, solo se puede utilizar el servicio Azure Key Vault. Para
más información sobre los escenarios de compatibilidad de las claves de cifrado de claves, consulte Creación y
configuración de un almacén de claves para Azure Disk Encryption.
¿Cuáles son los requisitos previos para configurar Azure Disk

Encryption?
Hay requisitos previos para Azure Disk Encryption. Consulte el artículo Creación y configuración de un almacén de
claves para Azure Disk Encryption para crear un almacén de claves o configurar un almacén de claves existente
para el acceso al cifrado de discos para habilitar el cifrado y proteger los secretos y las claves. Para más
información sobre los escenarios de compatibilidad de las claves de cifrado de claves, consulte Creación y
configuración de un almacén de claves para Azure Disk Encryption.
¿Cuáles son los requisitos previos para configurar Azure Disk
Encryption con una aplicación de Azure AD (versión anterior)?
Hay requisitos previos para Azure Disk Encryption. Consulte el contenido de Azure Disk Encryption con Azure AD
para crear una aplicación de Azure Active Directory, crear un almacén de claves o configurar el existente para el
acceso al cifrado de disco y habilitar el cifrado y proteger los secretos y las claves. Para más información sobre los
escenarios de compatibilidad de las claves de cifrado de claves, consulte Creación y configuración de un almacén
de claves para Azure Disk Encryption con Azure AD.
¿Sigue siendo compatible Azure Disk Encryption con una aplicación de

Azure AD (versión anterior)?
Sí. Todavía se admite el cifrado de disco mediante una aplicación de Azure AD. Sin embargo, al cifrar nuevas
máquinas virtuales, se recomienda utilizar el nuevo método en lugar de cifrar con una aplicación de Azure AD.
¿Se pueden migrar las máquinas virtuales cifradas con una aplicación
de Azure AD para el cifrado sin una aplicación de Azure AD?
En la actualidad, no existe una ruta de migración directa para los equipos que se cifraron con una aplicación de
Azure AD al cifrado sin una aplicación de Azure AD. Además, tampoco hay una ruta directa desde el cifrado sin una
aplicación Azure AD al cifrado con una aplicación de AD.
¿Qué versión de Azure PowerShell es compatible con Azure Disk

Encryption?
Utilice la versión más reciente del SDK de Azure PowerShell para configurar Azure Disk Encryption. Descargue la
versión más reciente de Azure PowerShell. La versión 1.1.0 del SDK de Azure no admite Azure Disk Encryption.
¿Qué es el disco "volumen Bek" o "/mnt/azure_bek_disk"?

El "volumen Bek" es un volumen de datos locales que almacena de forma segura las claves de cifrado de las
máquinas virtuales cifradas de Azure.
NOTE
No elimine ni modifique ningún contenido de este disco. No desmonte el disco ya que la presencia de la clave de cifrado es
necesaria para las operaciones de cifrado en la máquina virtual IaaS.
¿Qué método de cifrado usa Azure Disk Encryption?

Azure Disk Encryption usa el método de cifrado BitLocker AES256 (AES256WithDiffuser en versiones anteriores a
Windows Server 2012).
¿Si uso EncryptFormatAll y especifico todos los tipos de volumen se

borrarán los datos en las unidades de datos que ya hemos cifrado?
No, no se borran datos de las unidades de datos que ya estén cifradas mediante Azure Disk Encryption. Igual que
EncryptFormatAll no volvía a cifrar la unidad del SO, no volverá a cifrar la unidad de datos ya cifrada.
¿Puedo hacer una copia de seguridad de una VM cifrada y restaurarla?

Azure Backup proporciona un mecanismo para la copia de seguridad y restauración VM cifradas dentro de la
misma suscripción y región. Para obtener instrucciones, consulte Copia de seguridad y restauración de máquinas
virtuales cifradas con Azure Backup. Actualmente, no se admite la restauración de una VM cifrada en una región
diferente.
¿Dónde puedo formular preguntas o enviar comentarios?

Puede realizar preguntas o publicar comentarios en el Foro de Azure Disk Encryption.
Pasos siguientes
En este documento, aprendió más acerca de las preguntas más frecuentes sobre Azure Disk Encryption. Para
obtener más información acerca de este servicio, vea los siguientes artículos:
Aplicación de cifrado de discos en Azure Security Center
Cifrado de datos en reposo de Azure
Azure Disk Encryption con Azure AD (versión
anterior)
La nueva versión de Azure Disk Encryption elimina la necesidad de proporcionar un parámetro de

aplicación de Azure AD para habilitar el cifrado de disco de máquina virtual. Con la nueva versión, ya
no es necesario proporcionar credenciales de Azure AD durante el paso de habilitar el cifrado. Todas las
nuevas máquinas virtuales deben estar cifradas sin los parámetros de aplicación de Azure AD con la
nueva versión. Para conocer las instrucciones necesarias para habilitar el cifrado de disco de máquina
virtual mediante la nueva versión, consulte Azure Disk Encryption para máquinas virtuales Windows.
Las máquinas virtuales que ya se han cifrado con parámetros de aplicación de Azure AD se siguen
admitiendo y se deben seguir manteniendo con la sintaxis de AAD.
Este artículo complementa el artículo Azure Disk Encryption para máquinas virtuales Windows, ya que incluye
con requisitos adicionales y requisitos previos para Azure Disk Encryption con Azure AD (versión anterior). La
sección Máquinas virtuales y sistemas operativos compatibles no cambia.
Redes y directiva de grupo

Para habilitar la característica Azure Disk Encryption con la sintaxis de parámetro de ADD anterior, las
máquinas virtuales IaaS deben cumplir los siguientes requisitos de configuración de puntos de
conexión de red:
Para que un token se conecte al almacén de claves, la máquina virtual IaaS debe poder conectarse a un
punto de conexión de Azure Active Directory, [login.microsoftonline.com].
Para escribir las claves de cifrado en el almacén de claves, la máquina virtual IaaS debe poder conectarse al
punto de conexión del almacén de claves.
La máquina virtual IaaS debe poder conectarse al punto de conexión de Azure Storage que hospeda el
repositorio de extensiones de Azure y la cuenta de Azure Storage que hospeda los archivos VHD.
Si su directiva de seguridad limita el acceso desde máquinas virtuales de Azure a Internet, puede resolver
el URI anterior y configurar una regla concreta para permitir la conectividad de salida para las direcciones
IP. Para más información, consulte Azure Key Vault detrás de un firewall.
En Windows, si se deshabilitó explícitamente TLS 1.0 y la versión de .NET no se ha actualizado a la 4.6 o
posterior, el siguiente cambio en el registro habilitará ADE para seleccionar la versión más reciente de TLS:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001`
Directiva de grupo:
La solución Azure Disk Encryption usa el protector de claves externas de BitLocker para máquinas virtuales
IaaS con Windows. Para las máquinas virtuales unidas en un dominio, no cree ninguna directiva de grupo
que exija protectores de TPM. Para obtener información acerca de la directiva de grupo para "Permitir
BitLocker sin un TPM compatible", consulte la Referencia de la directiva de grupo de BitLocker.
La directiva de BitLocker en máquinas virtuales de unión a un dominio con directivas de grupo
personalizadas debe incluir la siguiente configuración: Configuración de almacenamiento de usuario de
información de recuperación de BitLocker -> Permitir clave de recuperación de 256 bits. Azure Disk
Encryption presentará un error cuando la configuración de la directiva de grupo personalizada para
BitLocker sea incompatible. En máquinas que no tengan la configuración de directiva correcta, puede que
sea necesario aplicar la nueva directiva, forzar la nueva directiva a actualizarse (gpupdate.exe /force) y
luego reiniciar.

Azure Disk Encryption requiere Azure Key Vault para controlar y administrar las claves y los secretos de cifrado de
discos. El almacén de claves y las VM deben residir en la misma región y suscripción de Azure.
Para más información, consulte Creación y configuración de un almacén de claves para Azure Disk Encryption
con Azure AD (versión anterior).
Pasos siguientes
Creación y configuración de un almacén de claves para Azure Disk Encryption con Azure AD (versión anterior)
Habilitación de Azure Disk Encryption con Azure AD en máquinas virtuales Windows (versión anterior)
Creación y configuración de un almacén de claves
para Azure Disk Encryption con Azure AD (versión
anterior)

no es necesario proporcionar credenciales de Azure AD durante el paso de habilitar el cifrado. Todas
las nuevas máquinas virtuales deben estar cifradas sin los parámetros de aplicación de Azure AD con
la nueva versión. Para ver las instrucciones necesarias para habilitar el cifrado de disco de máquina
virtual con la nueva versión, consulte Azure Disk Encryption. Las máquinas virtuales que ya se han
cifrado con parámetros de aplicación de Azure AD se siguen admitiendo y se deben seguir
manteniendo con la sintaxis de AAD.
Azure Disk Encryption usa Azure Key Vault para controlar y administrar las claves y los secretos de cifrado de
discos. Para más información sobre los almacenes de claves, consulte Introducción a Azure Key Vault y Protección
de un almacén de claves.
Para crear y configurar un almacén de claves para Azure Disk Encryption con Azure AD (versión anterior) debe
seguir estos tres pasos:
1. Cree un almacén de claves.
2. Configure una aplicación de Azure AD y una entidad de servicio.
3. Establezca la directiva de acceso del almacén de claves para la aplicación de Azure AD.
4. Configure las directivas de acceso avanzado del almacén de claves.
Si lo desea, también puede generar o importar una clave de cifrado de claves (KEK).
En el artículo Creación y configuración de un almacén de claves para Azure Disk Encryption encontrará los pasos
necesarios para instalar las herramientas y conectarse a Azure.
NOTE
Los pasos que se describen en este artículo se automatizan en el script de la CLI de requisitos previos de Azure Disk
Encryption y en el script de PowerShell de requisitos previos de Azure Disk Encryption.

Azure Disk Encryption se integra con Azure Key Vault para controlar y administrar los secretos y las claves de
cifrado de los discos en la suscripción de Key Vault. Puede crear un almacén de claves o usar uno existente para
Azure Disk Encryption. Para más información sobre los almacenes de claves, consulte Introducción a Azure Key
Vault y Protección de un almacén de claves. Puede usar una plantilla de Resource Manager, Azure PowerShell o
la CLI de Azure para crear un almacén de claves.
WARNING
Con el fin de garantizar que los secretos de cifrado no traspasen los límites regionales, Azure Disk Encryption necesita Key
Vault y las máquinas virtuales para ubicarse conjuntamente en la misma región. Cree y use una instancia de Key Vault que
se encuentre en la misma región que la máquina virtual que se va a cifrar.
Creación de un almacén de claves con PowerShell

Puede crear un almacén de claves con Azure PowerShell mediante el cmdlet New -AzKeyVault. Para otros cmdlets
de Key Vault, consulte Az.KeyVault.
1. Cree un nuevo grupo de recursos, si fuera necesario, con New -AzResourceGroup. Para enumerar las
ubicaciones de los centro de datos, use Get-AzLocation.
# Get-AzLocation
New-AzResourceGroup –Name 'MyKeyVaultResourceGroup' –Location 'East US'
2. Cree un nuevo almacén de claves con New -AzKeyVault.
New-AzKeyVault -VaultName 'MySecureVault' -ResourceGroupName 'MyKeyVaultResourceGroup' -Location 'East

US'
3. Tenga en cuenta el nombre del almacén, el nombre del grupo de recursos, el id. de recurso, el URI
de almacén y el id. de objeto que se devuelven para su uso posterior al cifrar los discos.
Creación de un almacén de claves con la CLI de Azure
Puede administrar el almacén de claves con la CLI de Azure mediante el comando az keyvault. Para crear un
almacén de claves, use crear az keyvault.
1. Cree un nuevo grupo de recursos, si es necesario, con crear grupo az. Para enumerar las ubicaciones, use
az account list-locations.
# To list locations: az account list-locations --output table

az group create -n "MyKeyVaultResourceGroup" -l "East US"
2. Cree un nuevo almacén de claves con crear az keyvault.
az keyvault create --name "MySecureVault" --resource-group "MyKeyVaultResourceGroup" --location "East

US"
3. Tenga en cuenta el nombre del almacén (nombre), el nombre del grupo de recursos, el id. de recurso
(identificador), el URI de almacén y el id. de objeto que se devuelven para su uso posterior.
Creación de un almacén de claves con una plantilla de Resource Manager
Puede crear un almacén de claves con la plantilla de Resource Manager.
2. Seleccione la suscripción, el grupo de recursos, la ubicación del grupo de recursos, el nombre del almacén de
claves, el id. de objeto, los términos legales y el contrato, y luego haga clic en Comprar.
Configuración de una aplicación de Azure AD y una entidad de

servicio
Si es preciso habilitar el cifrado en una máquina virtual en ejecución en Azure, Azure Disk Encryption genera y
escribe las claves de cifrado en su almacén de claves. La administración de claves de cifrado en el almacén de
claves necesita la autenticación de Azure AD. Para ello, cree una aplicación de Azure AD. Para realizar la
autenticación, se pueden usar la autenticación basada en secreto de cliente o la autenticación de Azure AD
basada en certificado del cliente.
Configuración de una aplicación de Azure AD y una entidad de servicio con Azure PowerShell
Para ejecutar los siguientes comandos, obtenga y use el módulo de PowerShell de Azure AD.
1. Use el cmdlet New -AzADApplication de PowerShell para crear una aplicación de Azure AD.
MyApplicationHomePage y MyApplicationUri pueden tener los valores que desee.
$aadClientSecret = "My AAD client secret"

$aadClientSecretSec = ConvertTo-SecureString -String $aadClientSecret -AsPlainText -Force
$azureAdApplication = New-AzADApplication -DisplayName "My Application Display Name" -HomePage
"https://MyApplicationHomePage" -IdentifierUris "https://MyApplicationUri" -Password
$aadClientSecretSec
$servicePrincipal = New-AzADServicePrincipal –ApplicationId $azureAdApplication.ApplicationId
2. $azureAdApplication.ApplicationId es el identificador de cliente de Azure AD y $aadClientSecret es el

secreto de cliente que usará posteriormente para habilitar Azure Disk Encryption. Proteja el secreto del
cliente de Azure AD apropiadamente. Ejecutar $azureAdApplication.ApplicationId mostrará el valor de
ApplicationID.
Configuración de una aplicación de Azure AD y una entidad de servicio con la CLI de Azure
Puede administrar las entidades de servicio con la CLI de Azure mediante el comando az ad sp. Para más
información, consulte Creación de una entidad de servicio de Azure.
1. Cree una nueva entidad de servicio.
az ad sp create-for-rbac --name "ServicePrincipalName" --password "My-AAD-client-secret" --skip-

assignment
2. El valor de appId devuelto es el identificador de cliente de Azure AD que se usa en otros comandos.
También es el SPN que se va a usar para az keyvault set-policy. La contraseña es el secreto de cliente que
se debe usar posteriormente para habilitar Azure Disk Encryption. Proteja el secreto del cliente de Azure
AD apropiadamente.
Configuración de una aplicación de Azure AD y una entidad de servicio desde Azure Portal
Siga los pasos que aparecen en el artículo Uso del portal para crear una aplicación de Azure Active Directory y
una entidad de servicio con acceso a los recursos para crear una aplicación de Azure AD. Cada paso que se
enumera a continuación lo llevará directamente a la sección del artículo que hay que completar.
1. Comprobar los permisos requeridos
2. Crear una aplicación de Azure Active Directory
Puede utilizar cualquier nombre y dirección URL de inicio de sesión que desee al crear la aplicación.
3. Obtener el identificador de aplicación y la clave de autenticación
La clave de autenticación es el secreto de cliente y se usa como el objeto AadClientSecret para Set-
AzVMDiskEncryptionExtension.
La aplicación usa la clave de autenticación como una credencial para iniciar sesión en Azure AD.
En Azure Portal, este secreto se denomina "claves", pero no tiene relación con los almacenes de
claves. Proteja adecuadamente este secreto.
El identificador de aplicación se usará más adelante como objeto AadClientId para Set-
AzVMDiskEncryptionExtension y como objeto ServicePrincipalName para Set-
AzKeyVaultAccessPolicy.
Establecimiento de la directiva de acceso del almacén de claves para la

aplicación de Azure AD
Para escribir los secretos de cifrado en un almacén de claves especificado, Azure Disk Encryption necesita el
identificador de cliente y el secreto de cliente de la aplicación de Azure Active Directory que tenga permisos para
escribir secretos en Key Vault.
NOTE
Azure Disk Encryption requiere que configure las siguientes directivas de acceso a la aplicación de cliente de Azure AD: los
permisos WrapKey y Set.
Establecimiento de la directiva de acceso del almacén de claves para la aplicación de Azure AD con Azure
PowerShell
La aplicación de Azure AD necesita derechos de acceso a las claves o secretos del almacén. Use el cmdlet Set-
AzKeyVaultAccessPolicy para conceder permisos a la aplicación, con el identificador de cliente (que se generó
cuando se registró la aplicación) como valor del parámetro –ServicePrincipalName. Para obtener más
información, consulte la entrada de blog Azure Key Vault - Step by Step (Azure Key Vault - Paso a paso).
1. Establezca la directiva de acceso del almacén de claves para la aplicación de AD con PowerShell.
$keyVaultName = 'MySecureVault'
$aadClientID = 'MyAadAppClientID'
$KVRGname = 'MyKeyVaultResourceGroup'
Set-AzKeyVaultAccessPolicy -VaultName $keyVaultName -ServicePrincipalName $aadClientID -
PermissionsToKeys 'WrapKey' -PermissionsToSecrets 'Set' -ResourceGroupName $KVRGname
Establecimiento de la directiva de acceso del almacén de claves para la aplicación de Azure AD con la CLI de
Azure
Use az keyvault set-policy para establecer la directiva de acceso. Para más información, consulte Administración
de Key Vault mediante CLI 2.0.
Conceda a la entidad de servicio que creó mediante la CLI de Azure accesp para obtener los secretos y
encapsular las claves con el comando siguiente:
```azurecli-interactive
az keyvault set-policy --name "MySecureVault" --spn "<spn created with CLI/the Azure AD ClientID>" --key-
permissions wrapKey --secret-permissions set
```
Establecimiento de la directiva de acceso del almacén de claves para la aplicación de Azure AD con el portal
1. Abra el grupo de recursos con el almacén de claves.
2. Seleccione el almacén de claves, vaya a Directivas de acceso y haga clic en Agregar nuevo.
3. En Select principal (Seleccionar la entidad de seguridad), busque la aplicación de Azure AD que creó y
selecciónela.
4. Para Permisos de claves, active Encapsular clave en Operaciones criptográficas.
5. Para Permisos de secretos, active Establecer en Operaciones de administración de secretos.
6. Haga clic en Aceptar para guardar la directiva de acceso.
Establecimiento de directivas de acceso avanzadas del almacén de
claves
La plataforma Azure necesita acceso a las claves de cifrado o secretos del almacén de claves para ponerlos a
disposición de la máquina virtual para el proceso de arranque y descifrado de los volúmenes. Habilite el cifrado
de disco en el almacén de claves o se producirá un error en las implementaciones.
Establecimiento de directivas de acceso avanzadas del almacén de claves con Azure PowerShell
Use el cmdlet Set-AzKeyVaultAccessPolicy de PowerShell del almacén de claves para habilitar el cifrado de disco
para el almacén de claves.
Habilitar Key Vault para el cifrado de disco: se requiere EnabledForDiskEncryption para el cifrado de
Azure Disk.
Set-AzKeyVaultAccessPolicy -VaultName 'MySecureVault' -ResourceGroupName 'MyKeyVaultResourceGroup' -

EnabledForDiskEncryption
Microsoft.Compute recupere los secretos de este almacén de claves cuando se hace referencia al almacén
de claves en la creación de recursos, por ejemplo, cuando se crea una máquina virtual.

EnabledForDeployment
Habilitar Key Vault para la implementación de plantillas, si es necesario: permite que Azure
Resource Manager obtenga los secretos de este almacén de claves cuando se hace referencia al almacén
de claves en una implementación de plantilla.

EnabledForTemplateDeployment
Establecimiento de directivas de acceso avanzadas del almacén de claves mediante la CLI de Azure
Use az keyvault update para habilitar el cifrado de disco para el almacén de claves.
Habilitar Key Vault para el cifrado de disco: Es necesario Enabled-for-disk-encryption.
az keyvault update --name "MySecureVault" --resource-group "MyKeyVaultResourceGroup" --enabled-for-

disk-encryption "true"
Habilitar Key Vault para la implementación, si es necesario: permite que Virtual Machines recupere
certificados almacenados como secretos del almacén.

deployment "true"
Habilitar Key Vault para la implementación de plantillas, si es necesario: permite que Resource
Manager recupere secretos del almacén.

template-deployment "true"
Establecimiento de directivas de acceso avanzadas del almacén de claves desde Azure Portal
1. Seleccione el almacén de claves, vaya a Directivas de acceso y Haga clic para mostrar las directivas de
acceso avanzado.
2. Active la casilla etiquetada Habilitar el acceso a Azure Disk Encryption para el cifrado de volúmenes.
3. Seleccione Habilitar el acceso a Azure Virtual Machines para la implementación o Habilitar el acceso
a Azure Resource Manager para la implementación de plantillas, si es necesario.
Configuración de una clave de cifrado de claves (KEK) (opcional)

Si desea usar una clave de cifrado de claves (KEK) para una brindar una capa adicional de seguridad para las
claves de cifrado, agregue una KEK a su almacén de claves. Use el cmdlet Add-AzKeyVaultKey para crear una
clave de cifrado de claves en el almacén de claves. También puede importar una KEK en el HSM de
administración de claves local. Para más información, consulte la documentación de Key Vault. Cuando se
especifica una clave de cifrado de claves, Azure Disk Encryption usa esa clave para encapsular los secretos de
cifrado antes de escribirlos en Key Vault.
Al generar las claves, use un tipo de clave RSA. Azure Disk Encryption no admite aún el uso de claves de
curva elíptica.
El secreto del almacén de claves y las direcciones URL de KEK deben tener versiones. Azure exige esta
restricción del control de versiones. Para ver direcciones URL de KEK y de secretos válidas, vea los
ejemplos siguientes:
Ejemplo de una dirección URL secreta válida:
https://contosovault.vault.azure.net/secrets/EncryptionSecretWithKek/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Ejemplo de una dirección URL de KEK válida:
https://contosovault.vault.azure.net/keys/diskencryptionkek/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Azure Disk Encryption no admite la especificación de números de puerto como parte de los secretos del
almacén de claves y las direcciones URL de KEK. Para ver ejemplos de direcciones URL de almacén de
claves admitidas y no admitidas, consulte los siguientes:
Dirección URL de almacén de claves inaceptable
https://contosovault.vault.azure.net:443/secrets/contososecret/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dirección URL de almacén de claves aceptable:
https://contosovault.vault.azure.net/secrets/contososecret/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Configuración de una clave de cifrado de claves con Azure PowerShell
Antes de usar el script de PowerShell, debe estar familiarizado con los requisitos previos de Azure Disk
Encryption para entender los pasos en el script. Es posible que el script de ejemplo requiera cambios para
adaptarse al entorno en cuestión. Este script crea todos los requisitos previos de Azure Disk Encryption y cifra
una máquina virtual IaaS existente, encapsulando la clave de cifrado de disco mediante el uso de una clave de
cifrado de claves.
# Step 1: Create a new resource group and key vault in the same location.
# Fill in 'MyLocation', 'MyKeyVaultResourceGroup', and 'MySecureVault' with your values.
# Use Get-AzLocation to get available locations and use the DisplayName.
# To use an existing resource group, comment out the line for New-AzResourceGroup
$Loc = 'MyLocation';
New-AzResourceGroup –Name $KVRGname –Location $Loc;
New-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname -Location $Loc;
$KeyVaultResourceId = (Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname).ResourceId;
$diskEncryptionKeyVaultUrl = (Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName
$KVRGname).VaultUri;
# Step 2: Create the AD application and service principal.

# Fill in 'MyAADClientSecret', "<My Application Display Name>", "<https://MyApplicationHomePage>", and "
<https://MyApplicationUri>" with your values.
# MyApplicationHomePage and the MyApplicationUri can be any values you wish.
$aadClientSecret = 'MyAADClientSecret';
$aadClientSecretSec = ConvertTo-SecureString -String $aadClientSecret -AsPlainText -Force;
$azureAdApplication = New-AzADApplication -DisplayName "<My Application Display Name>" -HomePage "
<https://MyApplicationHomePage>" -IdentifierUris "<https://MyApplicationUri>" -Password $aadClientSecretSec
$servicePrincipal = New-AzADServicePrincipal –ApplicationId $azureAdApplication.ApplicationId;
$aadClientID = $azureAdApplication.ApplicationId;
#Step 3: Enable the vault for disk encryption and set the access policy for the Azure AD application.
Set-AzKeyVaultAccessPolicy -VaultName $KeyVaultName -ResourceGroupName $KVRGname -

EnabledForDiskEncryption;
Set-AzKeyVaultAccessPolicy -VaultName $keyVaultName -ServicePrincipalName $aadClientID -PermissionsToKeys
'WrapKey' -PermissionsToSecrets 'Set' -ResourceGroupName $KVRGname;
#Step 4: Create a new key in the key vault with the Add-AzKeyVaultKey cmdlet.
# Fill in 'MyKeyEncryptionKey' with your value.
Add-AzKeyVaultKey -VaultName $KeyVaultName -Name $keyEncryptionKeyName -Destination 'Software';
$keyEncryptionKeyUrl = (Get-AzKeyVaultKey -VaultName $KeyVaultName -Name $keyEncryptionKeyName).Key.kid;
#Step 5: Encrypt the disks of an existing IaaS VM

# Fill in 'MySecureVM' and 'MyVirtualMachineResourceGroup' with your values.
$VMName = 'MySecureVM';
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGName -VMName $vmName -AadClientID $aadClientID -
AadClientSecret $aadClientSecret -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -
DiskEncryptionKeyVaultId $KeyVaultResourceId -KeyEncryptionKeyUrl $keyEncryptionKeyUrl -
KeyEncryptionKeyVaultId $KeyVaultResourceId;
Autenticación basada en certificados (opcional)

Si desea usar la autenticación de certificado, puede cargar uno en el almacén de claves e implementarlo en el
cliente. Antes de usar el script de PowerShell, debe estar familiarizado con los requisitos previos de Azure Disk
Encryption para entender los pasos en el script. Es posible que el script de ejemplo requiera cambios para
adaptarse al entorno en cuestión.
# Fill in "MyKeyVaultResourceGroup", "MySecureVault", and 'MyLocation' ('My location' only if needed)
$KeyVaultName= 'MySecureVault'
# Create a key vault and set enabledForDiskEncryption property on it.

# Comment out the next three lines if you already have an existing key vault enabled for encryption. No
need to set 'My location' in this case.
$Loc = 'MyLocation'
New-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname -Location $Loc
Set-AzKeyVaultAccessPolicy -VaultName $KeyVaultName -ResourceGroupName $KVRGname -EnabledForDiskEncryption
#Setting some variables with the key vault information

$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname
$DiskEncryptionKeyVaultUrl = $KeyVault.VaultUri
$KeyVaultResourceId = $KeyVault.ResourceId
# Create the Azure AD application and associate the certificate with it.
# Fill in "C:\certificates\mycert.pfx", "Password", "<My Application Display Name>", "
<https://MyApplicationHomePage>", and "<https://MyApplicationUri>" with your values.
# MyApplicationHomePage and the MyApplicationUri can be any values you wish
$CertPath = "C:\certificates\mycert.pfx"
$CertPassword = "Password"
$Cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($CertPath, $CertPassword)
$CertValue = [System.Convert]::ToBase64String($cert.GetRawCertData())
$AzureAdApplication = New-AzADApplication -DisplayName "<My Application Display Name>" -HomePage "

<https://MyApplicationHomePage>" -IdentifierUris "<https://MyApplicationUri>" -CertValue $CertValue
$ServicePrincipal = New-AzADServicePrincipal -ApplicationId $AzureAdApplication.ApplicationId
$AADClientID = $AzureAdApplication.ApplicationId
$aadClientCertThumbprint= $cert.Thumbprint

'WrapKey' -PermissionsToSecrets 'Set' -ResourceGroupName $KVRGname
# Upload the pfx file to the key vault.

# Fill in "MyAADCert".
$KeyVaultSecretName = "MyAADCert"
$FileContentBytes = get-content $CertPath -Encoding Byte
$FileContentEncoded = [System.Convert]::ToBase64String($fileContentBytes)
$JSONObject = @"
{
"data" : "$filecontentencoded",
"dataType" : "pfx",
"password" : "$CertPassword"
}
"@
$JSONObjectBytes = [System.Text.Encoding]::UTF8.GetBytes($jsonObject)
$JSONEncoded = [System.Convert]::ToBase64String($jsonObjectBytes)
#Set the secret and set the key vault policy for -EnabledForDeployment
$Secret = ConvertTo-SecureString -String $JSONEncoded -AsPlainText -Force

Set-AzKeyVaultSecret -VaultName $KeyVaultName -Name $KeyVaultSecretName -SecretValue $Secret
Set-AzKeyVaultAccessPolicy -VaultName $KeyVaultName -ResourceGroupName $KVRGname -EnabledForDeployment
# Deploy the certificate to the VM

$VMName = 'MySecureVM'
$VMRGName = 'MyVirtualMachineResourceGroup'
$CertUrl = (Get-AzKeyVaultSecret -VaultName $KeyVaultName -Name $KeyVaultSecretName).Id
$SourceVaultId = (Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGName).ResourceId
$VM = Get-AzVM -ResourceGroupName $VMRGName -Name $VMName
$VM = Add-AzVMSecret -VM $VM -SourceVaultId $SourceVaultId -CertificateStore "My" -CertificateUrl $CertUrl
Update-AzVM -VM $VM -ResourceGroupName $VMRGName
#Enable encryption on the VM using Azure AD client ID and the client certificate thumbprint
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGName -VMName $VMName -AadClientID $AADClientID -

AadClientCertThumbprint $AADClientCertThumbprint -DiskEncryptionKeyVaultUrl $DiskEncryptionKeyVaultUrl -
DiskEncryptionKeyVaultId $KeyVaultResourceId
Autenticación basada en certificados y una KEK (opcional)

Si desea usar la autenticación de certificado y encapsular la clave de cifrado con una KEK, puede usar el siguiente
script como ejemplo. Antes de usar el script de PowerShell, debe estar familiarizado con todos los requisitos
previos de Azure Disk Encryption anteriores para conocer los pasos en el script. Es posible que el script de
ejemplo requiera cambios para adaptarse al entorno en cuestión.
# Fill in 'MyKeyVaultResourceGroup', 'MySecureVault', and 'MyLocation' (if needed)
$KeyVaultName= 'MySecureVault'
# Create a key vault and set enabledForDiskEncryption property on it.

# Comment out the next three lines if you already have an existing key vault enabled for encryption.
$Loc = 'MyLocation'
New-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname -Location $Loc
Set-AzKeyVaultAccessPolicy -VaultName $KeyVaultName -ResourceGroupName $KVRGname -EnabledForDiskEncryption
# Create the Azure AD application and associate the certificate with it.
# Fill in "C:\certificates\mycert.pfx", "Password", "<My Application Display Name>", "
<https://MyApplicationHomePage>", and "<https://MyApplicationUri>" with your values.
# MyApplicationHomePage and the MyApplicationUri can be any values you wish
$CertPath = "C:\certificates\mycert.pfx"
$CertPassword = "Password"
$CertValue = [System.Convert]::ToBase64String($cert.GetRawCertData())
$AzureAdApplication = New-AzADApplication -DisplayName "<My Application Display Name>" -HomePage "

<https://MyApplicationHomePage>" -IdentifierUris "<https://MyApplicationUri>" -CertValue $CertValue
$ServicePrincipal = New-AzADServicePrincipal -ApplicationId $AzureAdApplication.ApplicationId
$AADClientID = $AzureAdApplication.ApplicationId
$aadClientCertThumbprint= $cert.Thumbprint
## Give access for setting secrets and wraping keys

'WrapKey' -PermissionsToSecrets 'Set' -ResourceGroupName $KVRGname
# Upload the pfx file to the key vault.

# Fill in "MyAADCert".
$KeyVaultSecretName = "MyAADCert"
$FileContentBytes = get-content $CertPath -Encoding Byte
$FileContentEncoded = [System.Convert]::ToBase64String($fileContentBytes)
$JSONObject = @"
{
"data" : "$filecontentencoded",
"dataType" : "pfx",
"dataType" : "pfx",
"password" : "$CertPassword"
}
"@
$JSONObjectBytes = [System.Text.Encoding]::UTF8.GetBytes($jsonObject)
$JSONEncoded = [System.Convert]::ToBase64String($jsonObjectBytes)
#Set the secret and set the key vault policy for deployment
$Secret = ConvertTo-SecureString -String $JSONEncoded -AsPlainText -Force

Set-AzKeyVaultSecret -VaultName $KeyVaultName -Name $KeyVaultSecretName -SecretValue $Secret
Set-AzKeyVaultAccessPolicy -VaultName $KeyVaultName -ResourceGroupName $KVRGname -EnabledForDeployment
#Setting some variables with the key vault information and generating a KEK
# FIll in 'KEKName'
$KEKName ='KEKName'
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname
$DiskEncryptionKeyVaultUrl = $KeyVault.VaultUri
$KeyVaultResourceId = $KeyVault.ResourceId
$KEK = Add-AzKeyVaultKey -VaultName $KeyVaultName -Name $KEKName -Destination "Software"
$KeyEncryptionKeyUrl = $KEK.Key.kid
# Deploy the certificate to the VM

$CertUrl = (Get-AzKeyVaultSecret -VaultName $KeyVaultName -Name $KeyVaultSecretName).Id
$SourceVaultId = (Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGName).ResourceId
$VM = Get-AzVM -ResourceGroupName $VMRGName -Name $VMName
$VM = Add-AzVMSecret -VM $VM -SourceVaultId $SourceVaultId -CertificateStore "My" -CertificateUrl $CertUrl
Update-AzVM -VM $VM -ResourceGroupName $VMRGName
#Enable encryption on the VM using Azure AD client ID and the client certificate thumbprint

KeyEncryptionKeyVaultId $KeyVaultResourceId
Pasos siguientes
Habilitación de Azure Disk Encryption con Azure AD en máquinas virtuales Windows (versión anterior)
Azure Disk Encryption con Azure AD para máquinas
virtuales Windows (versión anterior)

no es necesario proporcionar credenciales de Azure AD durante el paso de habilitar el cifrado. Todas
las nuevas máquinas virtuales deben estar cifradas sin los parámetros de aplicación de Azure AD con la
nueva versión. Para instrucciones sobre cómo habilitar el cifrado de disco de máquina virtual con la
nueva versión, consulte Azure Disk Encryption para máquinas virtuales de Windows. Las máquinas
virtuales que ya se han cifrado con parámetros de aplicación de Azure AD se siguen admitiendo y se
deben seguir manteniendo con la sintaxis de AAD.
Puede habilitar muchos escenarios de cifrado de disco, y los pasos pueden variar en función del escenario. En las
secciones siguientes se tratan con más detalle los escenarios de máquinas virtuales IaaS de Windows. Para poder
usar el cifrado de disco, es necesario satisfacer los requisitos previos de Azure Disk Encryption.
IMPORTANT
Es preciso hacer una instantánea o crear una copia de seguridad antes de cifrar los discos. Las copias de seguridad
garantizan que, en caso de un error inesperado durante el cifrado, sea posible una opción de recuperación. Las
máquinas virtuales con discos administrados requieren una copia de seguridad antes del cifrado. Una vez realizada la
copia de seguridad, puede usar el cmdlet Set-AzVMDiskEncryptionExtension para cifrar los discos administrados
mediante la especificación del parámetro -skipVmBackup. Para más información sobre cómo realizar la copia de
seguridad y la restauración de máquinas virtuales cifradas, consulte Copia de seguridad y restauración de máquinas
virtuales de Azure cifradas.
Cifrar o deshabilitar el cifrado puede provocar el reinicio de una máquina virtual.
Habilitación del cifrado en nuevas máquinas virtuales IaaS creadas en

Marketplace
Puede habilitar el cifrado de disco en nuevas máquinas virtuales IaaS de Windows desde Marketplace en Azure
mediante la plantilla de Resource Manager. La plantilla crea una máquina virtual Windows cifrada mediante la
imagen de la galería de Windows Server 2012.
1. En la plantilla de Resource Manager, haga clic en Deploy to Azure (Implementar en Azure).
2. Seleccione la suscripción, el grupo de recursos, la ubicación del grupo de recursos, los parámetros, los
términos legales y el contrato. Haga clic en Comprar para implementar una nueva máquina virtual IaaS
donde esté habilitado el cifrado.
3. Después de implementar la plantilla, compruebe el estado de cifrado de la máquina virtual con su método
preferido:
Realice la comprobación con la CLI de Azure con el comando az vm encryption show.
Realice la comprobación con Azure PowerShell a través del comando Get-

AzVmDiskEncryptionStatus.
Get-AzVmDiskEncryptionStatus -ResourceGroupName 'MyVirtualMachineResourceGroup' -VMName

'MySecureVM'
Seleccione la máquina virtual y haga clic en Discos en el encabezado Configuración para

comprobar el estado de cifrado en el portal. En el gráfico que aparece en Cifrado, verá si está
habilitado.
En la tabla siguiente figuran los parámetros de la plantilla de Resource Manager para nuevas máquinas virtuales
en el escenario de Marketplace con el identificador de cliente de Azure AD:
adminUserName Nombre de usuario administrador para la máquina virtual.
adminPassword Contraseña de usuario administrador para la máquina virtual.
newStorageAccountName Nombre de la cuenta de almacenamiento que almacena el

sistema operativo y los VHD de datos.
vmSize Tamaño de la máquina virtual. Actualmente, solo se admiten

las series A, D y G estándar.
virtualNetworkName Nombre de la red virtual a la que debería pertenecer la NIC

de la máquina virtual.
subnetName Nombre de la subred en la red virtual a la que debería

pertenecer la NIC de la máquina virtual.
AADClientID Identificador de cliente de la aplicación de Azure AD que tiene

permisos para escribir secretos en el almacén de claves.
AADClientSecret Secreto de cliente de la aplicación de Azure AD que tiene

keyVaultURL Dirección URL del almacén de claves en el que se que debe

cargar la clave de BitLocker. Puede obtenerla mediante el
cmdlet
(Get-AzKeyVault -VaultName "MyKeyVault" -
ResourceGroupName
"MyKeyVaultResourceGroupName").VaultURI
o la CLI de Azure
az keyvault show --name "MySecureVault" --query
properties.vaultUri
keyEncryptionKeyURL Dirección URL de la clave de cifrado de claves que se utiliza

para cifrar la clave generada por BitLocker (opcional).
KeyEncryptionKeyURL es un parámetro opcional. Puede

aportar su propia KEK para proteger aún más la clave de
cifrado de datos (frase de contraseña secreta) en el almacén
de claves.
keyVaultResourceGroup Grupo de recursos del almacén de claves.
vmName Nombre de la máquina virtual en que se va a realizar la

operación de cifrado.
Habilitación del cifrado en máquinas virtuales IaaS de Windows

existentes o en ejecución
En este escenario, puede habilitar el cifrado mediante una plantilla, los cmdlets de PowerShell o los comandos de
la CLI. En las siguientes secciones se explica con más detalle cómo habilitar Azure Disk Encryption.
Habilitación del cifrado en máquinas virtuales existentes o en ejecución con Azure PowerShell
Use el cmdlet Set-AzVMDiskEncryptionExtension para habilitar el cifrado en una máquina virtual IaaS en
ejecución en Azure. Para obtener información acerca de cómo habilitar el cifrado con Azure Disk Encryption
mediante el uso de cmdlets de PowerShell, vea las entradas de blog Explore Azure Disk Encryption with Azure
PowerShell - Part 1 (Exploración de Azure Disk Encryption con Azure PowerShell - Parte 1) y Explore Azure Disk
Encryption with Azure PowerShell - Part 2 (Exploración de Azure Disk Encryption con Azure PowerShell - Parte
2 ).
Cifrar una máquina virtual en ejecución mediante un secreto de cliente: el siguiente script inicializa
las variables y ejecuta el cmdlet Set-AzVMDiskEncryptionExtension. Ya se deben haber satisfecho los
requisitos previos de crear el grupo de recursos, la máquina virtual, el almacén de claves, la aplicación de
AAD y el secreto de cliente. Reemplace MyKeyVaultResourceGroup, MyVirtualMachineResourceGroup,
MySecureVM, MySecureVault, My-AAD -client-ID y My-AAD -client-secret por sus propios valores.
$aadClientID = 'My-AAD-client-ID';
$aadClientSecret = 'My-AAD-client-secret';
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGName -VMName $vmName -AadClientID

$aadClientID -AadClientSecret $aadClientSecret -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -
DiskEncryptionKeyVaultId $KeyVaultResourceId;
Cifrar una máquina virtual en ejecución con KEK para encapsular el secreto de cliente: Azure Disk
Encryption le permite especificar una clave existente en el almacén de claves para encapsular los secretos
de cifrado de disco que se generaron al habilitar el cifrado. Cuando se especifica una clave de cifrado de
claves, Azure Disk Encryption usa esa clave para encapsular los secretos de cifrado antes de escribirlos en
Key Vault.
$vmName = ‘MyExtraSecureVM’;
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGname -VMName $vmName -AadClientID $aadClientID

-AadClientSecret $aadClientSecret -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -
KeyEncryptionKeyVaultId $KeyVaultResourceId;
NOTE
de IaaS, use el cmdlet Get-AzVmDiskEncryptionStatus.
Get-AzVmDiskEncryptionStatus -ResourceGroupName 'MyVirtualMachineResourceGroup' -VMName 'MySecureVM'
Deshabilitar el cifrado de disco: para deshabilitar el cifrado, use el cmdlet Disable-

AzureRmVMDiskEncryption.

Habilitación del cifrado en máquinas virtuales existentes o en ejecución con la CLI de Azure
Use el comando az vm encryption enable para habilitar el cifrado en una máquina virtual IaaS en ejecución en
Azure.
Cifrar una máquina virtual en ejecución mediante un secreto de cliente:
az vm encryption enable --resource-group "MyVirtualMachineResourceGroup" --name "MySecureVM" --aad-

client-id "<my spn created with CLI/my Azure AD ClientID>" --aad-client-secret "My-AAD-client-secret"
--disk-encryption-keyvault "MySecureVault" --volume-type [All|OS|Data]
Cifrar una máquina virtual en ejecución con KEK para encapsular el secreto de cliente:

client-id "<my spn created with CLI which is the Azure AD ClientID>" --aad-client-secret "My-AAD-
client-secret" --disk-encryption-keyvault "MySecureVault" --key-encryption-key "MyKEK_URI" --key-
encryption-keyvault "MySecureVaultContainingTheKEK" --volume-type [All|OS|Data]
NOTE
IaaS, use el comando az vm encryption show.
Deshabilitar el cifrado: para deshabilitar el cifrado, use el comando az vm encryption disable.
az vm encryption disable --name "MySecureVM" --resource-group "MyVirtualMachineResourceGroup" --

volume-type [ALL, DATA, OS]
Uso de la plantilla de Resource Manager

Puede habilitar el cifrado de disco en máquinas virtuales IaaS de Windows existentes o en ejecución en Azure
mediante la plantilla de Resource Manager para cifrar una máquina virtual Windows en ejecución.
2. Seleccione la suscripción, el grupo de recursos, la ubicación del grupo de recursos, los parámetros, los
términos legales y el contrato. Haga clic en Comprar para habilitar el cifrado en la máquina virtual IaaS
existente o en ejecución.
En la tabla siguiente figuran los parámetros de la plantilla de Resource Manager para máquinas virtuales
existentes o en ejecución que usan un identificador de cliente de Azure AD:
AADClientID Identificador de cliente de la aplicación de Azure AD que tiene

AADClientSecret Secreto de cliente de la aplicación de Azure AD que tiene

keyVaultName Nombre del almacén de claves en el que se que debe cargar

la clave de BitLocker. Puede obtenerlo mediante el cmdlet
(Get-AzKeyVault -ResourceGroupName
<MyKeyVaultResourceGroupName>). Vaultname
o el comando de la CLI de Azure
az keyvault list --resource-group "MySecureGroup"
keyEncryptionKeyURL Dirección URL de la clave de cifrado de claves que se utiliza

para cifrar la clave generada por BitLocker. Este parámetro es
opcional si selecciona nokek en la lista desplegable de
UseExistingKek. Si selecciona kek en la lista desplegable de
UseExistingKek, debe proporcionar el valor de
keyEncryptionKeyURL.
volumeType Tipo de volumen en que se realiza la operación de cifrado. Los

valores válidos son SO, Datos y Todo.
sequenceVersion Versión de la secuencia de la operación de BitLocker.

Incremente el número de versión cada vez que se realice una
operación de cifrado de disco en la misma máquina virtual.
vmName Nombre de la máquina virtual en que se va a realizar la

operación de cifrado.
Máquinas virtuales IaaS creadas a partir de discos duros virtuales

cifrados y claves de cifrado
En este escenario, se puede habilitar el cifrado mediante la plantilla de Resource Manager, cmdlets de PowerShell
o comandos de la CLI. Las siguientes secciones explican con más detalle la plantilla de Resource Manager y los
comandos de la CLI.
Use las instrucciones del apéndice para preparar imágenes previamente cifradas que se pueden usar en Azure.
Una vez creada la imagen, puede seguir los pasos de la sección siguiente para crear una VM cifrada de Azure.
Preparación de un VHD con Windows precifrado
Cifrado de máquinas virtuales con discos duros virtuales previamente cifrados con Azure PowerShell
Puede habilitar el cifrado de disco en el disco duro virtual cifrado mediante el cmdlet Set-AzVMOSDisk de
PowerShell. En el ejemplo siguiente se proporcionan algunos parámetros comunes.
$VirtualMachine = New-AzVMConfig -VMName "MySecureVM" -VMSize "Standard_A1"

$VirtualMachine = Set-AzVMOSDisk -VM $VirtualMachine -Name "SecureOSDisk" -VhdUri "os.vhd" Caching ReadWrite
-Windows -CreateOption "Attach" -DiskEncryptionKeyUrl
"https://mytestvault.vault.azure.net/secrets/Test1/514ceb769c984379a7e0230bddaaaaaa" -
DiskEncryptionKeyVaultId "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myKVresourcegroup/providers/Microsoft.KeyVault/vaults/mytestvault"
New-AzVM -VM $VirtualMachine -ResourceGroupName "MyVirtualMachineResourceGroup"
Habilitación del cifrado en un disco de datos recién agregado

También puede agregar un nuevo disco a una máquina virtual Windows con PowerShell o mediante Azure Portal.
Habilitación del cifrado en un disco recién agregado con Azure PowerShell
Al usar PowerShell para cifrar un nuevo disco para máquinas virtuales Windows, se debe especificar una nueva
versión de secuencia. La versión de secuencia debe ser única. El siguiente script genera un GUID para la versión
de secuencia. En algunos casos, un disco de datos recién agregado se podría cifrar automáticamente mediante la
extensión Azure Disk Encryption. El cifrado automático suele producirse cuando se reinicia la máquina virtual
después de que el nuevo disco se pone en línea. Esto se suele producir porque se especificó "All" para el tipo de
volumen cuando el cifrado de disco se ejecutó anteriormente en la máquina virtual. Si el cifrado automático se
produce en un disco de datos recién agregado, se recomienda volver a ejecutar el cmdlet Set-
AzVmDiskEncryptionExtension con la nueva versión de secuencia. Si el nuevo disco de datos es de cifrado
automático y no desea cifrarlo, descifre todas las unidades en primer lugar y, a continuación, vuelva a cifrarlas con
una nueva versión de secuencia que especifique el sistema operativo para el tipo de volumen.
Cifrar una máquina virtual en ejecución mediante un secreto de cliente: el siguiente script inicializa
las variables y ejecuta el cmdlet Set-AzVMDiskEncryptionExtension. Ya se deben haber satisfecho los
requisitos previos de crear el grupo de recursos, la máquina virtual, el almacén de claves, la aplicación de
AAD y el secreto de cliente. Reemplace MyKeyVaultResourceGroup, MyVirtualMachineResourceGroup,
MySecureVM, MySecureVault, My-AAD -client-ID y My-AAD -client-secret por sus propios valores. Este
ejemplo utiliza "All" para el parámetro -VolumeType, que incluye los volúmenes de sistema operativo y de
datos. Si solo quiere cifrar el volumen del sistema operativo, use "OS" para el parámetro VolumeType.
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGname -VMName $vmName -AadClientID

$aadClientID -AadClientSecret $aadClientSecret -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -
DiskEncryptionKeyVaultId $KeyVaultResourceId -VolumeType 'all' –SequenceVersion $sequenceVersion;
Cifrar una máquina virtual en ejecución con KEK para encapsular el secreto de cliente: Azure Disk
Encryption le permite especificar una clave existente en el almacén de claves para encapsular los secretos
de cifrado de disco que se generaron al habilitar el cifrado. Cuando se especifica una clave de cifrado de
claves, Azure Disk Encryption usa esa clave para encapsular los secretos de cifrado antes de escribirlos en
Key Vault. Este ejemplo utiliza "All" para el parámetro -VolumeType, que incluye los volúmenes de sistema
operativo y de datos. Si solo quiere cifrar el volumen del sistema operativo, use "OS" para el parámetro
VolumeType.
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGname -VMName $vmName -AadClientID $aadClientID

-AadClientSecret $aadClientSecret -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -
KeyEncryptionKeyVaultId $KeyVaultResourceId -VolumeType 'all' –SequenceVersion $sequenceVersion;
NOTE
Habilitación del cifrado en un disco recién agregado con la CLI de Azure

El comando de la CLI de Azure proporciona automáticamente una nueva versión de secuencia al ejecutarlo para
habilitar el cifrado. Los valores aceptables para el parámetro volumen-type son All, OS y Data. Es posible que
deba cambiar el parámetro volume-type para SO o Data si solo se está cifrando un tipo de disco para la VM. Los
ejemplos usan "All" para el parámetro de volume-type.
Cifrar una máquina virtual en ejecución mediante un secreto de cliente:

client-id "<my spn created with CLI/my Azure AD ClientID>" --aad-client-secret "My-AAD-client-secret"
--disk-encryption-keyvault "MySecureVault" --volume-type "All"
Cifrar una máquina virtual en ejecución con KEK para encapsular el secreto de cliente:

client-id "<my spn created with CLI which is the Azure AD ClientID>" --aad-client-secret "My-AAD-
client-secret" --disk-encryption-keyvault "MySecureVault" --key-encryption-key "MyKEK_URI" --key-
encryption-keyvault "MySecureVaultContainingTheKEK" --volume-type "all"
Habilite el cifrado mediante la autenticación basada en certificados de

cliente de Azure AD.
Puede usar la autenticación de certificado de cliente con o sin KEK. Antes de usar los scripts de PowerShell, ya
debe tener el certificado cargado en el almacén de claves e implementado en la máquina virtual. Si también usa
KEK, ya debe existir KEK. Para más información, consulte la sección Autenticación basada en certificados de Azure
AD del artículo de requisitos previos.
Habilitación del cifrado mediante la autenticación basada en certificados con Azure PowerShell
## Fill in 'MyVirtualMachineResourceGroup', 'MyKeyVaultResourceGroup', 'My-AAD-client-ID', 'MySecureVault,
and ‘MySecureVM’.
$VMRGName = 'MyVirtualMachineResourceGroup'
$AADClientID ='My-AAD-client-ID';
# Fill in the certificate path and the password so the thumbprint can be set as a variable.
$certPath = '$CertPath = "C:\certificates\mycert.pfx';

$CertPassword ='Password'
$aadClientCertThumbprint = $cert.Thumbprint;
# Enable disk encryption using the client certificate thumbprint

DiskEncryptionKeyVaultId $KeyVaultResourceId
Habilitación del cifrado mediante la autenticación basada en certificados y KEK con Azure PowerShell
# Fill in 'MyVirtualMachineResourceGroup', 'MyKeyVaultResourceGroup', 'My-AAD-client-ID', 'MySecureVault,,

'MySecureVM’, and "KEKName.
$AADClientID ='My-AAD-client-ID';
$keyEncryptionKeyName ='KEKName';
$keyEncryptionKeyUrl = (Get-AzKeyVaultKey -VaultName $KeyVaultName -Name $keyEncryptionKeyName).Key.kid;
## Fill in the certificate path and the password so the thumbprint can be read and set as a variable.
$certPath = '$CertPath = "C:\certificates\mycert.pfx';

$CertPassword ='Password'
$aadClientCertThumbprint = $cert.Thumbprint;
# Enable disk encryption using the client certificate thumbprint and a KEK

KeyEncryptionKeyVaultId $KeyVaultResourceId
Deshabilitación del cifrado

Puede deshabilitar el cifrado con Azure PowerShell, la CLI de Azure o una plantilla de Resource Manager.
Deshabilitar el cifrado de disco con Azure PowerShell: para deshabilitar el cifrado, use el cmdlet
Disable-AzureRmVMDiskEncryption.
Deshabilitar el cifrado con la CLI de Azure: para deshabilitar el cifrado, use el comando az vm
encryption disable.
az vm encryption disable --name "MySecureVM" --resource-group "MyVirtualMachineResourceGroup" --

volume-type [ALL, DATA, OS]
Deshabilitar el cifrado con una plantilla de Resource Manager:

1. Haga clic en Deploy to Azure (Implementar en Azure) en la plantilla Deshabilitar el cifrado de disco en
una máquina virtual Windows en ejecución.
2. Seleccione la suscripción, el grupo de recursos, la ubicación, la máquina virtual, los términos legales y el
contrato.
3. Haga clic en Comprar para deshabilitar el cifrado de disco en una máquina virtual Windows en
ejecución.
Pasos siguientes
Configuración de acceso a WinRM para máquinas
virtuales en Azure Resource Manager
Estos son los pasos que debe seguir para configurar una máquina virtual con conectividad de WinRM.
1. Creación de un almacén de claves
2. Creación de un certificado autofirmado
3. Carga del certificado autofirmado en Key Vault
4. Obtención de la dirección URL para el certificado autofirmado en el almacén de claves.
5. Referencia a la dirección URL de los certificados autofirmados durante la creación de una máquina virtual
Paso 1: Creación de un almacén de claves

Puede utilizar el siguiente comando para crear el almacén de claves:
New-AzKeyVault -VaultName "<vault-name>" -ResourceGroupName "<rg-name>" -Location "<vault-location>" -

EnabledForDeployment -EnabledForTemplateDeployment
Paso 2: Creación de un certificado autofirmado

Puede crear un certificado autofirmado mediante este script de PowerShell:
$certificateName = "somename"
$thumbprint = (New-SelfSignedCertificate -DnsName $certificateName -CertStoreLocation Cert:\CurrentUser\My -

KeySpec KeyExchange).Thumbprint
$cert = (Get-ChildItem -Path cert:\CurrentUser\My\$thumbprint)
$password = Read-Host -Prompt "Please enter the certificate password." -AsSecureString
Export-PfxCertificate -Cert $cert -FilePath ".\$certificateName.pfx" -Password $password
Paso 3: Carga del certificado autofirmado en Key Vault

Antes de cargar el certificado en el almacén de claves que creó en el paso 1, debe convertirlo a un formato que
entienda el proveedor de recursos Microsoft.Compute. El siguiente script de PowerShell le permitirá hacer eso:
$fileName = "<Path to the .pfx file>"
$fileContentBytes = Get-Content $fileName -Encoding Byte
$fileContentEncoded = [System.Convert]::ToBase64String($fileContentBytes)
$jsonObject = @"
{
"data": "$filecontentencoded",
"dataType" :"pfx",
"password": "<password>"
}
"@
$jsonObjectBytes = [System.Text.Encoding]::UTF8.GetBytes($jsonObject)
$jsonEncoded = [System.Convert]::ToBase64String($jsonObjectBytes)
$secret = ConvertTo-SecureString -String $jsonEncoded -AsPlainText –Force

Set-AzKeyVaultSecret -VaultName "<vault name>" -Name "<secret name>" -SecretValue $secret
Paso 4: Obtención de la dirección URL para el certificado autofirmado

en el almacén de claves.
El proveedor de recursos Microsoft.Compute necesita una dirección URL al secreto en el almacén de claves
durante el aprovisionamiento de la máquina virtual. De esta manera, dicho proveedor podrá descargar el secreto y
crear el certificado equivalente en la máquina virtual.
NOTE
La dirección URL del secreto debe incluir también la versión. Este es un ejemplo de una dirección URL de este tipo:
https://contosovault.vault.azure.net:443/secrets/contososecret/01h9db0df2cd4300a20ence585a6s7ve
Plantillas
Puede obtener el vínculo a la dirección URL en la plantilla mediante el siguiente código:
"certificateUrl": "[reference(resourceId(resourceGroup().name, 'Microsoft.KeyVault/vaults/secrets', '<vault-

name>', '<secret-name>'), '2015-06-01').secretUriWithVersion]"
PowerShell
Puede obtener esta dirección URL mediante el siguiente comando de PowerShell:
$secretURL = (Get-AzKeyVaultSecret -VaultName "<vault name>" -Name "<secret name>").Id
Paso 5: Referencia a la dirección URL de los certificados autofirmados

durante la creación de una máquina virtual
Plantillas del Administrador de recursos de Azure
Al crear una máquina virtual mediante plantillas, se hace referencia al certificado en la sección de secretos y en la
sección de WinRM de la manera siguiente:
"osProfile": {
...
"secrets": [
{
"sourceVault": {
"id": "<resource id of the Key Vault containing the secret>"
},
"vaultCertificates": [
{
"certificateUrl": "<URL for the certificate you got in Step 4>",
"certificateStore": "<Name of the certificate store on the VM>"
}
]
}
],
"windowsConfiguration": {
...
"winRM": {
"listeners": [
{
"protocol": "http"
},
{
"protocol": "https",
"certificateUrl": "<URL for the certificate you got in Step 4>"
}
]
},
...
}
},
Una plantilla de ejemplo para el caso mencionado se puede encontrar aquí en 201-vm-winrm-keyvault-windows
El código fuente de esta plantilla está disponible en GitHub
PowerShell
$vm = New-AzVMConfig -VMName "<VM name>" -VMSize "<VM Size>"

$credential = Get-Credential
$secretURL = (Get-AzKeyVaultSecret -VaultName "<vault name>" -Name "<secret name>").Id
$vm = Set-AzVMOperatingSystem -VM $vm -Windows -ComputerName "<Computer Name>" -Credential $credential -
WinRMHttp -WinRMHttps -WinRMCertificateUrl $secretURL
$sourceVaultId = (Get-AzKeyVault -ResourceGroupName "<Resource Group name>" -VaultName "<Vault
Name>").ResourceId
$CertificateStore = "My"
$vm = Add-AzVMSecret -VM $vm -SourceVaultId $sourceVaultId -CertificateStore $CertificateStore -CertificateUrl
$secretURL
Paso 6: Conexión a la VM
Antes de poder conectarse a la máquina virtual, debe asegurarse de que el equipo esté configurado para la
administración remota de WinRM. Inicie PowerShell como administrador y ejecute el siguiente comando para
asegurarse de que se encuentra en el programa de instalación.
Enable-PSRemoting -Force
NOTE
Si la solución anterior no funciona, debe asegurarse de que el servicio WinRM esté en ejecución. Para ello, utilice
Get-Service WinRM
Cuando haya finalizado la instalación, puede conectarse a la máquina virtual mediante el comando siguiente:
Enter-PSSession -ConnectionUri https://<public-ip-dns-of-the-vm>:5986 -Credential $cred -SessionOption (New-

PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck) -Authentication Negotiate
¿Qué es el control de acceso basado en rol (RBAC)
para los recursos de Azure?
La administración de acceso de los recursos en la nube es una función importantísima para cualquier
organización que use la nube. El control de acceso basado en rol (RBAC ) ayuda a administrar quién puede
acceder a los recursos de Azure, qué pueden hacer con esos recursos y a qué áreas pueden acceder.
RBAC es un sistema de autorización basado en Azure Resource Manager que proporciona administración de
acceso específico a los recursos de Azure.
¿Qué puedo hacer con RBAC?

Estos son algunos ejemplos de lo que puede hacer con RBAC:
Permitir que un usuario administre las máquinas virtuales de una suscripción y que otro usuario administre las
redes virtuales
Permitir que un grupo de DBA administre bases de datos SQL en una suscripción
Permitir que un usuario administre todos los recursos de un grupo de recursos, como las máquinas virtuales,
los sitios web y las subredes
Permitir que una aplicación acceda a todos los recursos de un grupo de recursos
Procedimiento recomendado para el uso de RBAC

También podrá repartir las tareas entre el equipo y conceder a los usuarios únicamente el nivel de acceso que
necesitan para realizar su trabajo. En lugar de proporcionar a todos los empleados permisos no restringidos en
los recursos o la suscripción de Azure, puede permitir solo determinadas acciones en un ámbito concreto.
Al planear la estrategia de control de acceso, es recomendable conceder a los usuarios el privilegio mínimo para
que realicen su trabajo. El siguiente diagrama muestra un patrón sugerido para la asignación de RBAC.
Funcionamiento de RBAC
La manera en que se controla el acceso a los recursos mediante RBAC es mediante las asignaciones de roles. Este
es un concepto clave que se debe entender: se trata de cómo se aplican los permisos. Una asignación de roles
consta de tres elementos: entidad de seguridad, definición de rol y ámbito.
Entidad de seguridad
Una entidad de seguridad es un objeto que representa a un usuario, un grupo, una entidad de servicio o una
identidad administrada que solicita acceso a recursos de Azure.
Usuario: individuo que tiene un perfil en Azure Active Directory. También puede asignar roles a usuarios de
otros inquilinos. Para información sobre los usuarios de otras organizaciones, consulte el artículo sobre la
colaboración B2B de Azure Active Directory.
Grupo: conjunto de usuarios creado en Azure Active Directory. Cuando se asigna un rol a un grupo, todos los
usuarios dentro de ese grupo tienen ese rol.
Entidad de servicio: identidad de seguridad que las aplicaciones o los servicios usan para acceder a recursos
específicos de Azure. Puede considerarla como una identidad de usuario (nombre de usuario y contraseña o
certificado) de una aplicación.
Identidad administrada: una identidad de Azure Active Directory que Azure administra de forma automática.
Normalmente, se usan identidades administradas cuando se desarrollan aplicaciones en la nube para
administrar las credenciales para la autenticación en los servicios de Azure.
Definición de roles
Una definición de roles es una recopilación de permisos. A veces, se denomina rol simplemente. Una definición de
roles enumera las operaciones que se pueden realizar, por ejemplo, de lectura, escritura y eliminación. Los roles
pueden ser generales, como propietarios, o específicos, como lectores de máquina virtual.
Azure incluye varios roles integrados que puede usar. A continuación se enumeran cuatros roles integrados
fundamentales. Los tres primeros se aplican a todos los tipos de recursos.
Propietario: tiene acceso total a todos los recursos, incluido el derecho a delegar este acceso a otros.
Colaborador: puede crear y administrar todos los tipos de recursos de Azure pero no puede conceder acceso a
otros.
Lector: puede ver los recursos existentes de Azure.
Administrador de acceso de usuario: permite administrar el acceso de los usuarios a los recursos de Azure.
Los demás roles integrados permiten la administración de recursos específicos de Azure. Por ejemplo, el rol
Colaborador de máquina virtual permite al usuario crear y administrar máquinas virtuales. Si los roles integrados
no cumplen las necesidades específicas de su organización, puede crear sus propios roles personalizados para los
recursos de Azure.
Azure tiene operaciones de datos que le permiten conceder acceso a los datos dentro de un objeto. Por ejemplo, si
un usuario tiene acceso para leer datos de una cuenta de almacenamiento, puede leer los blobs o mensajes en esa
cuenta de almacenamiento. Para más información, consulte Descripción de definiciones de roles para los recursos
de Azure.
Ámbito
Ámbito es el conjunto de recursos al que se aplica el acceso. Cuando se asigna un rol, es posible limitar aún más
las acciones permitidas si se define un ámbito. Esto resulta útil si desea convertir a alguien en Colaborador del
sitio web, pero solo para un grupo de recursos.
En Azure, puede especificar un ámbito en varios niveles: grupo de administración, suscripción, grupo de recursos
o recurso. Los ámbitos se estructuran en una relación de elementos primarios y secundarios.
Si otorga acceso a un ámbito primario, esos permisos se heredan en los ámbitos secundarios. Por ejemplo:
Si asigna el rol Propietario a un usuario del ámbito del grupo de administración, ese usuario puede
administrar todo en todas las suscripciones del grupo de administración.
Si asigna el rol Lector a un grupo en el ámbito de la suscripción, los miembros de ese grupo pueden ver cada
grupo de recursos y cada recurso de la suscripción.
Si asigna el rol Colaborador a una aplicación en el ámbito del grupo de recursos, puede administrar recursos
de todos los tipos en ese grupo de recursos, pero no otros grupo de recursos de la suscripción.
Asignaciones de roles
Una asignación de roles es el proceso de asociar una definición de roles a un usuario, grupo, entidad de servicio o
identidad administrada en un ámbito determinado con el fin de conceder acceso. El acceso se concede mediante
la creación de una asignación de roles y se revoca al quitar una asignación de roles.
El diagrama siguiente muestra un ejemplo de una asignación de roles. En este ejemplo, al grupo de marketing se
le asignó el rol Colaborador del grupo de recursos de ventas farmacéuticas. Esto significa que los usuarios del
grupo de marketing pueden crear o administrar cualquier recurso de Azure del grupo de recursos de ventas
farmacéuticas. Los usuarios de marketing no tienen acceso a los recursos fuera del grupo de recursos de ventas
farmacéuticas, a menos que sean parte de otra asignación de roles.
Puede crear asignaciones de roles mediante Azure Portal, la CLI de Azure, Azure PowerShell, los SDK de Azure o
las API de REST. Puede tener hasta 2000 asignaciones de roles en cada suscripción y 500 asignaciones de roles
en cada grupo de administración. Para crear y quitar las asignación de roles, debe tener el permiso
Microsoft.Authorization/roleAssignments/* . Este permiso se concede a través de los roles Propietario o
Administrador de acceso de usuario.
Asignaciones de varios roles

Por tanto, ¿qué ocurre si tiene varias asignaciones de roles que se superponen? RBAC es un modelo de suma, por
lo que los permisos efectivos son la suma de las asignaciones de rol. Considere el ejemplo siguiente, donde a un
usuario se le concede el rol Colaborador en el ámbito de la suscripción y el rol Lector en un grupo de recursos. La
adición de los permisos de Colaborador y los permisos de Lector es realmente el rol Colaborador del grupo de
recursos. Por consiguiente, en este caso, la asignación del rol Lector no tiene ningún impacto.
Asignaciones de denegación
Anteriormente, RBAC era un modelo solo de permiso sin denegación, pero ahora RBAC admite asignaciones de
denegación de manera limitada. De forma similar a una asignación de roles, una asignación de denegación asocia
un conjunto de acciones de denegación a un usuario, grupo, entidad de servicio o identidad administrada en un
ámbito determinado con el fin de denegar el acceso. Una asignación de roles define un conjunto de acciones que
están permitidas, mientras que una asignación de denegación define un conjunto de acciones no permitidas. En
otras palabras, denegar asignaciones impide que los usuarios realicen acciones especificadas, incluso si una
asignación de roles les concede acceso. Las asignaciones de denegación tienen prioridad sobre las asignaciones
de roles. Para más información, consulte Descripción de las asignaciones de denegación para recursos de Azure.
Cómo determina RBAC si un usuario tiene acceso a un recurso

Los siguientes son los pasos de alto nivel que RBAC usa para determinar si tiene acceso a un recurso en el plano
de administración. Esto resulta útil para saber si está intentando solucionar un problema de acceso.
1. Un usuario (o entidad de servicio) adquiere un token de Azure Resource Manager.
El token incluye pertenencias de grupo del usuario (incluida la pertenencia a grupos transitivos).
2. El usuario realiza una llamada de API REST a Azure Resource Manager con el token adjunto.
3. Azure Resource Manager recupera todas las asignaciones de roles y de denegación aplicables al recurso en
el que se está realizando la acción.
4. Azure Resource Manager limita las asignaciones de roles aplicables a este usuario o su grupo y determina
los roles que tiene el usuario para este recurso.
5. Azure Resource Manager determina si la acción en la llamada de API se incluye en los roles que tiene el
usuario para este recurso.
6. Si el usuario no tiene un rol con la acción en el ámbito solicitado, no se concede acceso. En caso contrario,
Azure Resource Manager comprueba si se aplica una asignación de denegación.
7. Si se aplica una asignación de denegación, el acceso se bloquea. En caso contrario, se concede el acceso.
Requisitos de licencia
El uso de esta característica es gratis y está incluido en su suscripción de Azure.
Pasos siguientes
Inicio rápido: Visualización del acceso de un usuario a los recursos de Azure mediante Azure Portal
Administración del acceso a los recursos de Azure mediante RBAC y Azure Portal
Descripción de los distintos roles en Azure
Adopción de la nube empresarial: Administración del acceso a recursos de Azure
Aplicar directivas a máquinas virtuales con Windows
con Azure Resource Manager
Mediante las directivas, una organización puede aplicar varias convenciones y reglas en toda la empresa. La
aplicación del comportamiento deseado puede ayudar a reducir el riesgo a la vez que se contribuye al éxito de la
organización. En este artículo, describimos cómo puede usar las directivas de Azure Resource Manager para
definir el comportamiento deseado para las máquinas virtuales de su organización.
Si desea una introducción a las directivas, consulte ¿Qué es Azure Policy?.
Máquinas virtuales permitidas

Para asegurarse de que las máquinas virtuales de la organización son compatibles con una aplicación, puede
restringir los sistemas operativos permitidos. En el ejemplo de directiva siguiente, solo se permite que se creen
máquinas virtuales de Windows Server 2012 R2 Datacenter:
{
"if": {
"allOf": [
{
"field": "type",
"in": [
"Microsoft.Compute/disks",
"Microsoft.Compute/virtualMachines",
"Microsoft.Compute/VirtualMachineScaleSets"
]
},
{
"not": {
"allOf": [
{
"field": "Microsoft.Compute/imagePublisher",
"in": [
"MicrosoftWindowsServer"
]
},
{
"field": "Microsoft.Compute/imageOffer",
"in": [
"WindowsServer"
]
},
{
"field": "Microsoft.Compute/imageSku",
"in": [
"2012-R2-Datacenter"
]
},
{
"field": "Microsoft.Compute/imageVersion",
"in": [
"latest"
]
}
]
}
}
]
},
"then": {
"effect": "deny"
}
}
Use un carácter comodín para modificar la directiva anterior para permitir cualquier imagen de Windows Server
Datacenter:
{
"like": "*Datacenter"
}
Use anyOf para modificar la directiva anterior para permitir cualquier imagen de Windows Server 2012 R2
Datacenter o superior:
{
"anyOf": [
{
"like": "2012-R2-Datacenter*"
},
{
"like": "2016-Datacenter*"
}
]
}
Para obtener información sobre los campos de directiva, vea Alias de directiva.
Discos administrados
Para requerir el uso de discos administrados, use la siguiente directiva:
{
"if": {
"anyOf": [
{
"allOf": [
{
"field": "type",
"equals": "Microsoft.Compute/virtualMachines"
},
{
"field": "Microsoft.Compute/virtualMachines/osDisk.uri",
"exists": true
}
]
},
{
"allOf": [
{
"field": "type",
"equals": "Microsoft.Compute/VirtualMachineScaleSets"
},
{
"anyOf": [
{
"field": "Microsoft.Compute/VirtualMachineScaleSets/osDisk.vhdContainers",
"exists": true
},
{
"field": "Microsoft.Compute/VirtualMachineScaleSets/osdisk.imageUrl",
"exists": true
}
]
}
]
}
]
},
"then": {
"effect": "deny"
}
}
Imágenes para las máquinas virtuales

Por motivos de seguridad, puede obligar a que solo las imágenes personalizadas aprobadas se puedan
implementar en su entorno. Puede especificar el grupo de recursos que contiene las imágenes aprobadas o las
imágenes aprobadas específicas.
En el ejemplo siguiente se requieren imágenes de un grupo de recursos aprobado:
{
"if": {
"allOf": [
{
"field": "type",
"in": [
"Microsoft.Compute/virtualMachines",
"Microsoft.Compute/VirtualMachineScaleSets"
]
},
{
"not": {
"field": "Microsoft.Compute/imageId",
"contains": "resourceGroups/CustomImage"
}
}
]
},
"then": {
"effect": "deny"
}
}
En el ejemplo siguiente se especifican los identificadores de las imágenes aprobadas:
{
"field": "Microsoft.Compute/imageId",
"in": ["{imageId1}","{imageId2}"]
}
Extensiones de máquina virtual

Puede que desee prohibir el uso de ciertos tipos de extensiones. Por ejemplo, una extensión puede no ser
compatible con determinadas imágenes personalizadas de máquina virtual. En el ejemplo siguiente se muestra
cómo bloquear una extensión específica. Utiliza el anunciante y el tipo para determinar qué extensiones se van a
bloquear.
{
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Compute/virtualMachines/extensions"
},
{
"field": "Microsoft.Compute/virtualMachines/extensions/publisher",
"equals": "Microsoft.Compute"
},
{
"field": "Microsoft.Compute/virtualMachines/extensions/type",
"equals": "{extension-type}"
}
]
},
"then": {
"effect": "deny"
}
}
Ventaja de uso híbrido de Azure

Si tiene una licencia local, puede ahorrarse la tarifa de la licencia en sus máquinas virtuales. Si no dispone de la
licencia, debe prohibir la opción. La siguiente directiva prohíbe el uso de la ventaja de uso híbrido de Azure
(AHUB ):
{
"if": {
"allOf": [
{
"field": "type",
"in":[ "Microsoft.Compute/virtualMachines","Microsoft.Compute/VirtualMachineScaleSets"]
},
{
"field": "Microsoft.Compute/licenseType",
"exists": true
}
]
},
"then": {
"effect": "deny"
}
}
Pasos siguientes
Después de definir una regla de directiva (como se muestra en los ejemplos anteriores), debe crear la definición
de directiva y asignarla a un ámbito. El ámbito puede ser una suscripción, un grupo de recursos o un recurso.
Para asignar directivas, consulte Uso de Azure Portal para asignar y administrar directivas de recursos, Uso de
PowerShell para asignar directivas o Uso de la CLI de Azure para asignar directivas.
Si desea una introducción a las directivas de recursos, consulte ¿Qué es Azure Policy?.
Para obtener instrucciones sobre cómo las empresas pueden utilizar Resource Manager para administrar
eficazmente las suscripciones, vea Scaffold empresarial de Azure: Gobernanza de suscripción prescriptiva.
Configuración de Key Vault para máquinas virtuales
en Azure Resource Manager
NOTE
Azure tiene dos modelos de implementación diferentes que puede utilizar para crear recursos y trabajar con ellos: Azure
Resource Manager y clásico. Este artículo trata sobre el modelo de implementación del Administrador de recursos. Se
recomienda usar el modelo de implementación de Resource Manager para las nuevas implementaciones, en lugar del modelo
de implementación clásica.
En la pila de Azure Resource Manager, los certificados o secretos se modelan como recursos que se proporcionan
mediante el proveedor de recursos de Key Vault. Para más información sobre Key Vault, consulte ¿Qué es Azure
Key Vault?
NOTE
1. Para poder usar Key Vault con máquinas virtuales de Azure Resource Manager, la propiedad EnabledForDeployment de
Key Vault se debe establecer en true. Puede hacer esto en varios clientes.
2. El almacén de claves debe crearse en la misma ubicación y suscripción que la máquina virtual.
Uso de PowerShell para configurar Key Vault

Para crear un almacén de claves con PowerShell, vea Establecimiento y recuperación de un secreto de Azure Key
Vault mediante PowerShell.
Para almacenes de claves nuevos, puede usar este cmdlet de PowerShell:
New-AzKeyVault -VaultName 'ContosoKeyVault' -ResourceGroupName 'ContosoResourceGroup' -Location 'East Asia' -

EnabledForDeployment
Para almacenes de claves existentes, puede usar este cmdlet de PowerShell:
Set-AzKeyVaultAccessPolicy -VaultName 'ContosoKeyVault' -EnabledForDeployment
Uso de la CLI para configurar Key Vault

Para crear un almacén de claves mediante la interfaz de la línea de comandos (CLI), consulte Administración de
Key Vault mediante la CLI.
Para la CLI, primero debe crear el almacén de claves y luego asignar la directiva de implementación. Para ello,
puede usar el siguiente comando:
az keyvault create --name "ContosoKeyVault" --resource-group "ContosoResourceGroup" --location "EastAsia"
A continuación, para habilitar Key Vault de modo que se use con la implementación de plantilla, ejecute el
siguiente comando:
az keyvault update --name "ContosoKeyVault" --resource-group "ContosoResourceGroup" --enabled-for-deployment
"true"
Uso de plantillas para configurar Key Vault

Al utilizar plantillas, deberá establecer la propiedad enabledForDeployment en true para el recurso de Key Vault.
{
"type": "Microsoft.KeyVault/vaults",
"name": "ContosoKeyVault",
"apiVersion": "2015-06-01",
"location": "<location-of-key-vault>",
"properties": {
"enabledForDeployment": "true",
....
....
}
}
Para otras opciones que puede configurar al crear un almacén de claves mediante plantillas, consulte Create a key
vault(Creación de un almacén de claves).
2 minutes to read
Copia de seguridad de una máquina virtual en Azure
con la CLI
La CLI de Azure se usa para crear y administrar recursos de Azure desde la línea de comandos o en scripts. Para
proteger sus datos realice copias de seguridad a intervalos regulares. Azure Backup crea puntos de recuperación
que se guardan en almacenes de recuperación con redundancia geográfica. En este artículo se explica cómo
realizar una copia de seguridad de una máquina virtual (VM ) en Azure con la CLI de Azure. Estos pasos también
se pueden llevar a cabo con Azure PowerShell o en Azure Portal.
Esta guía de inicio rápido permite realizar copias de seguridad en una máquina virtual de Azure existente. Si
necesita crear una máquina virtual, puede crearla con la CLI de Azure.

local.




3. Pegue el código en la sesión de Cloud Shell; para ello, seleccione Ctrl+Shift+V en Windows y Linux, o bien
seleccione Cmd+Shift+V en macOS.
Para instalar y usar la CLI localmente, debe ejecutar la versión 2.0.18 de la CLI de Azure o una posterior. Para
averiguar la versión de la CLI, ejecute az --version . Si necesita instalarla o actualizarla, consulte Instalación de la
CLI de Azure.
Creación de un almacén de Servicios de recuperación

Un almacén de Recovery Services es un contenedor lógico que almacena los datos de copia de seguridad de los
recursos protegidos, como las máquinas virtuales de Azure. Cuando se ejecuta el trabajo de copia de seguridad
para un recurso protegido, crea un punto de recuperación en el almacén de Recovery Services. Posteriormente, se
puede usar uno de estos puntos de recuperación para restaurar los datos a un momento dado en el tiempo.
Cree un almacén de Recovery Services con az backup vault create. Especifique el mismo grupo de recursos y
ubicación que tenga la máquina virtual que desea proteger. Si ha usado el inicio rápido de la máquina virtual,
habrá creado lo siguiente:
un grupo de recursos denominado myResourceGroup;
una máquina virtual denominada myVM;
recursos en la ubicación eastus.
az backup vault create --resource-group myResourceGroup \

--name myRecoveryServicesVault \
--location eastus
De forma predeterminada, el almacén de Recovery Services se establece para el almacenamiento con redundancia
geográfica. El almacenamiento con redundancia geográfica garantiza que se repliquen los datos de copia de
seguridad en una región de Azure secundaria que se encuentra a cientos de kilómetros de distancia de la región
primaria. Si es necesario modificar la configuración de la redundancia del almacenamiento, utilice el cmdlet az
backup vault backup-properties set.
az backup vault backup-properties set \

--backup-storage-redundancy "LocallyRedundant/GeoRedundant"
Habilitación de la copia de seguridad de una máquina virtual de Azure

Cree y use directivas para definir cuándo se ejecuta un trabajo de copia de seguridad y durante cuánto tiempo se
almacenan los puntos de recuperación. La directiva de protección predeterminada ejecuta un trabajo de copia de
seguridad cada día y conserva los puntos de seguridad durante 30 días. Estos valores de la directiva
predeterminada se pueden usar para proteger rápidamente la máquina virtual. Para habilitar la protección
mediante copia de seguridad de una máquina virtual, use az backup protection enable-for-vm. Especifique el
grupo de recursos y la máquina virtual que se van a proteger, y la directiva que se va a usar:
az backup protection enable-for-vm \

--vault-name myRecoveryServicesVault \
--vm myVM \
--policy-name DefaultPolicy
NOTE
Si la máquina virtual no está en el mismo grupo de recursos que el almacén, myResourceGroup hará referencia al grupo de
recursos donde se creó el almacén. En lugar del nombre de la máquina virtual, proporcione el identificador de la máquina
virtual como se indica a continuación.
az backup protection enable-for-vm \
--vm $(az vm show -g VMResourceGroup -n MyVm --query id | tr -d '"') \
--policy-name DefaultPolicy
IMPORTANT
Al usar la CLI para habilitar la copia de seguridad de varias máquinas virtuales a la vez, asegúrese de que una sola directiva
no tenga más de 100 máquinas virtuales asociadas. Este es un procedimiento recomendado. Actualmente, el cliente de PS no
bloquea explícitamente si hay más de 100 máquinas virtuales, pero está previsto que la comprobación se agregue en el
futuro.
Inicio de un trabajo de copia de seguridad

Para iniciar una copia de seguridad ahora, en lugar de esperar a que la directiva predeterminada ejecute el trabajo
en el momento programado, utilice az backup protection backup-now. El primer trabajo de copia de seguridad
crea un punto de recuperación completa. Cada uno de los trabajo de copia de seguridad posteriores a esta copia
de seguridad inicial crea puntos de recuperación incremental. Los puntos de recuperación incremental ahorran
tiempo y espacio de almacenamiento, ya que solo transfieren los cambios realizados desde la última copia de
seguridad.
Los siguientes parámetros se utilizan para hacer una copia de seguridad de la máquina virtual:
--container-name es el nombre de la máquina virtual
--item-name es el nombre de la máquina virtual
El valor --retain-until se debe establecerse en la última fecha disponible, en formato de hora UTC (dd-mm -
aaaa), en que desea que el punto de recuperación esté disponible
En el ejemplo siguiente se realiza una copia de la máquina virtual denominada myVM y se establece la expiración
del punto de recuperación para el 18 de octubre de 2017:
az backup protection backup-now \

--container-name myVM \
--item-name myVM \
--retain-until 18-10-2017
Supervisión del trabajo de copia de seguridad

Para supervisar el estado de los trabajos de copia de seguridad, use az backup job list:
az backup job list \

--output table
La salida es similar al ejemplo siguiente, que muestra que el estado del trabajo de copia de seguridad es
InProgress:
Name Operation Status Item Name Start Time UTC Duration
-------- --------------- ---------- ----------- ------------------- --------------
a0a8e5e6 Backup InProgress myvm 2017-09-19T03:09:21 0:00:48.718366
fe5d0414 ConfigureBackup Completed myvm 2017-09-19T03:03:57 0:00:31.191807
Cuando el apartado Status (Estado) del trabajo de copia de seguridad muestre Completed (Completado), la
máquina virtual estará protegida con Recovery Services y tendrá almacenado un punto de recuperación completa.
Cuando deje de ser necesaria, puede deshabilitar la protección en la máquina virtual, quitar los puntos de
restauración y el almacén de Recovery Services, y eliminar tanto el grupo de recursos como los recursos de la
máquina virtual asociados. Si ha usado una máquina virtual existente, puede omitir el última comando az group
delete para dejar tanto el grupo de recursos como la máquina virtual en su lugar.
Si desea seguir un tutorial de Backup en el que se explique cómo restaurar los datos en una máquina virtual, vaya
a Pasos siguientes.
az backup protection disable \

--item-name myVM \
--delete-backup-data true
az backup vault delete \
Pasos siguientes
En esta guía de inicio rápido, ha creado un almacén de Recovery Services, ha habilitado la protección en una
máquina virtual y ha creado el punto de recuperación inicial. Para más información acerca de Azure Backup, y
Recovery Services, continúe con los tutoriales.
Copia de seguridad de varias máquinas virtuales de Azure
Uso de Azure Portal para realizar la copia de
seguridad de varias máquinas virtuales
Al realizar una copia de seguridad de datos en Azure, almacena esos datos en un recurso de Azure que se
denomina “almacén de Recovery Services”. El recurso de almacén de Recovery Services está disponible en el menú
Configuración de la mayoría de los servicios de Azure. La ventaja de tener el almacén de Recovery Services
integrado en el menú Configuración de la mayoría de los servicios de Azure facilita la copia de seguridad de datos.
Sin embargo, resulta tedioso trabajar individualmente con cada base de datos o máquina virtual de la empresa.
¿Qué ocurre si desea realizar una copia de seguridad de los datos de todas las máquinas virtuales de un
departamento o una ubicación? Es fácil realizar la copia de seguridad de varias máquinas virtuales mediante la
creación de una directiva de copia de seguridad y la aplicación de esa directiva a las máquinas virtuales deseadas.
Este tutorial explica cómo realizar lo siguiente:
Creación de un almacén de Recovery Services
Definición de una directiva de copia de seguridad
Aplicación de la directiva de copia de seguridad para proteger varias máquinas virtuales
Desencadenamiento de un trabajo de copia de seguridad a petición para las máquinas virtuales protegidas
Inicio de sesión en Azure Portal


El almacén de Recovery Services contiene los datos de la copia de seguridad y la directiva de copia de seguridad
que se aplica a las máquinas virtuales protegidas. La copia de seguridad de máquinas virtuales es un proceso local.
No puede hacer copias de seguridad de una máquina virtual de una ubicación en un almacén de Recovery Services
que está en otra ubicación. Por lo tanto, para cada ubicación de Azure que tenga máquinas virtuales de las que se
tengan que realizar copias de seguridad, debe existir al menos un almacén de Recovery Services en esa ubicación.
1. En el menú izquierdo, seleccione Todos los servicios y, en la lista de servicios, escriba Recovery Services. A
medida que escribe, se filtra la lista de recursos. Cuando vea la opción Almacenes de Recovery Services en
la lista, selecciónela para abrir el menú Almacenes de Recovery Services.
2. En el menú Almacenes de Recovery Services, haga clic en Agregar para abrir el menú Almacén de
Recovery Services.
3. En el menú Almacén de Recovery Services,
escriba myRecoveryServicesVault en Nombre.
El id. de suscripción actual aparecerá en Suscripción. Si tiene suscripciones adicionales, puede elegir
otra suscripción para el nuevo almacén.
En Grupo de recursos, seleccione Usar existente y elija myResourceGroup. Si myResourceGroup no
existe, seleccione Crear nuevo y escriba myResourceGroup.
En el menú desplegable Ubicación, elija Europa Occidental.
Haga clic en Crear para crear el almacén de Recovery Services.
Un almacén de Recovery Services debe estar en la misma ubicación que las máquinas virtuales que se están
protegiendo. Si tiene máquinas virtuales en varias regiones, cree un almacén de Recovery Services en cada una de
ellas. En este tutorial se crea un almacén de Recovery Services en Europa Occidental, porque es la ubicación donde
se creó myVM (la máquina virtual creada con el inicio rápido).
La creación del almacén de Recovery Services puede tardar unos minutos. Supervise las notificaciones de estado
de la parte superior derecha del portal. Una vez creado el almacén, aparece en la lista de almacenes de Recovery
Services.
Cuando se crea un almacén de Recovery Services, este tiene almacenamiento con redundancia geográfica de
forma predeterminada. Para proporcionar resistencia de datos, el almacenamiento con redundancia geográfica
replica los datos varias veces en dos regiones de Azure.
Establecer la directiva de copia de seguridad para proteger las

máquinas virtuales
Después de crear el almacén de Recovery Services, el siguiente paso es configurar el almacén para el tipo de datos
y establecer la directiva de copia de seguridad. La directiva de copia de seguridad es la programación de la
frecuencia y el momento de captura de los puntos de recuperación. La directiva también incluye el intervalo de
retención de los puntos de recuperación. Para este tutorial, supongamos que su empresa es un complejo deportivo
con un hotel, estadio, restaurantes y concesiones, y que va a proteger los datos en las máquinas virtuales. En los
pasos siguientes, se crea una directiva de copia de seguridad de los datos financieros.
1. En la lista Almacenes de Recovery Services, seleccione myRecoveryServicesVault para abrir su panel.
2. En el menú del panel del almacén, haga clic en Copia de seguridad para abrir el menú Copia de seguridad.
3. En el menú Objetivo de Backup, en el menú desplegable ¿Dónde se ejecuta su carga de trabajo? , elija
Azure. En la lista desplegable ¿De qué desea hacer una copia de seguridad? , elija Máquina virtual y
luego haga clic en Copia de seguridad.
Estas acciones preparan el almacén de Recovery Services para interactuar con una máquina virtual. Los
almacenes de Recovery Services tienen una directiva predeterminada que crea un punto de restauración al
día y conserva los puntos de restauración durante 30 días.
4. Para crear una nueva directiva, en el menú desplegable Elegir directiva de copia de seguridad del menú
Directiva de copia de seguridad, seleccione Crear nueva.
5. En el menú Directiva de copia de seguridad, en Nombre de directiva, escriba Finanzas. Especifique los
siguientes cambios para la directiva de copia de seguridad:
Para Frecuencia de copia de seguridad, establezca la zona horaria en Hora central. Puesto que el
complejo deportivo se encuentra en Texas, el propietario desea usar la hora local. Deje la frecuencia
de copia de seguridad establecida en Diaria a las 3:30 a.m.
En Retención de punto de copia de seguridad diaria, establezca el período en 90 días.
En Retención de punto de copia de seguridad semanal, use el punto de restauración Lunes y
consérvelo 52 semanas.
En Retención de punto de copia de seguridad mensual, use el punto de restauración desde el
primer domingo del mes y el consérvelo 36 meses.
Anule la selección de la opción Retención de punto de copia de seguridad anual. El director de
Finanzas no desea mantener los datos más allá de 36 meses.
Haga clic en Aceptar para crear la directiva de copia de seguridad.
Después de crear la directiva de copia de seguridad, asóciela a las máquinas virtuales.
6. En el cuadro de diálogo Seleccionar máquinas virtuales, elija myVM y haga clic en Aceptar para
implementar la directiva de copia de seguridad en las máquinas virtuales.
Aparecen todas las máquinas virtuales que estén en la misma ubicación y no estén asociadas todavía con
una directiva de copia de seguridad. myVMH1 y myVMR1 se seleccionan para asociarse a la directiva
Finanzas.
Cuando se complete la implementación, recibirá una notificación para indicarle que se completó
correctamente.
Copia de seguridad inicial

Ha habilitado la copia de seguridad de los almacenes de Recovery Services, pero no se ha creado la copia de
seguridad inicial. Es un procedimiento recomendado de recuperación ante desastres para desencadenar la primera
copia de seguridad, de modo que sus datos estén protegidos.
Para ejecutar un trabajo de copia de seguridad a petición:
1. En el panel del almacén, haga clic en 3 en Elementos de copia de seguridad para abrir el menú
Elementos de copia de seguridad.
Se abrirá el menú Elementos de copia de seguridad.
2. En el menú Elementos de copia de seguridad, haga clic en Máquina Virtual de Azure para abrir la lista
de máquinas virtuales asociadas con el almacén.
Se abrirá la lista Elementos de copia de seguridad.
3. En la lista Elementos de copia de seguridad, haga clic en el botón de puntos suspensivos ... para abrir el
menú contextual.
4. En el menú contextual, seleccione Realizar copia de seguridad ahora.
Se abrirá el menú Realizar copia de seguridad ahora.

5. En el menú Realizar copia de seguridad ahora, especifique el último día para conservar el punto de
recuperación y haga clic en Copia de seguridad.
Las notificaciones de implementación le permiten saber si se ha desencadenado el trabajo de copia de

seguridad y que puede supervisar el progreso del trabajo en la página de trabajos de copia de seguridad.
Según el tamaño de la máquina virtual, la creación de la copia de seguridad inicial puede tardar cierto
tiempo.
Cuando se complete el trabajo de copia de seguridad inicial, puede ver su estado en el menú Trabajo de
copia de seguridad. El trabajo de copia de seguridad a petición creó el punto de restauración inicial de
myVM. Si desea hacer una copia de seguridad de otras máquinas virtuales, repita estos pasos para cada una
de ellas.
Si tiene previsto seguir trabajando con los tutoriales siguientes, no elimine los recursos creados en este tutorial. Si
no tiene previsto continuar, siga estos pasos para eliminar todos los recursos creados en este tutorial en Azure
Portal.
1. En el panel myRecoveryServicesVault, haga clic en 3 en Elementos de copia de seguridad para abrir el
menú Elementos de copia de seguridad.
2. En el menú Elementos de copia de seguridad, haga clic en Máquina Virtual de Azure para abrir la lista
de máquinas virtuales asociadas con el almacén.
Se abrirá la lista Elementos de copia de seguridad.

3. En el menú Elementos de copia de seguridad, haga clic en los puntos suspensivos para abrir el menú
contextual.
4. En el menú contextual, seleccione Detener copia de seguridad para abrir el menú Detener copia de
seguridad.
5. En el menú Detener copia de seguridad, seleccione el menú desplegable superior y elija Eliminar datos
de copia de seguridad.
6. En el cuadro de diálogo Escriba el nombre del elemento de copia de seguridad, escriba myVM.
7. Una vez comprobado el elemento de copia de seguridad (aparece una marca de verificación), se habilita el
botón Detener copia de seguridad. Haga clic en Detener copia de seguridad para detener la directiva y
eliminar los puntos de restauración.
8. En el menú myRecoveryServicesVault, haga clic en Eliminar.

Una vez eliminado el almacén, se volverá a mostrar la lista de almacenes de Recovery Services.
Pasos siguientes
En este tutorial se usa Azure Portal para las siguientes acciones:
Configurar el almacén para proteger las máquinas virtuales
Crear una directiva de retención y copia de seguridad personalizada
Asignar la directiva para proteger varias máquinas virtuales
Desencadenar la copia de seguridad a petición de las máquinas virtuales
Continúe con el tutorial siguiente para restaurar una máquina virtual de Azure desde el disco.
Restaurar máquinas virtuales mediante la CLI
Restauración de un disco y creación de una máquina
virtual recuperada en Azure
Azure Backup crea puntos de recuperación que se almacenan en almacenes de recuperación con redundancia
geográfica. Cuando se realiza una restauración desde un punto de recuperación, se puede restaurar toda una
máquina virtual o archivos individuales. En este artículo se explica cómo restaurar una máquina virtual completa
mediante la CLI. En este tutorial, aprenderá a:
Enumerar y seleccionar puntos de recuperación
Restaurar un disco desde un punto de recuperación
Crear una máquina virtual a partir del disco restaurado
Para información sobre cómo usar PowerShell para restaurar un disco y crear una máquina virtual recuperada,
consulte Copia de seguridad y restauración de máquinas virtuales de Azure con PowerShell.

preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno local.




Si decide instalar y usar la CLI localmente, para este tutorial es preciso que ejecute la CLI de Azure versión 2.0.18 o
posterior. Ejecute az --version para encontrar la versión. Si necesita instalarla o actualizarla, consulte Instalación
de la CLI de Azure.
Requisitos previos
Para este tutorial se necesita una máquina virtual Linux protegida con Azure Backup. Para simular un proceso de
recuperación y eliminación de máquina virtual accidental, cree una máquina virtual desde un disco en un punto de
recuperación. Si necesita una máquina virtual Linux que esté protegida con Azure Backup, consulte Copia de
seguridad de una máquina virtual en Azure con la CLI.
Cuando Azure inicia una copia de seguridad, la extensión de copia de seguridad en la máquina virtual toma una
instantánea de un momento dado. La extensión de copia de seguridad se instala en la máquina virtual cuando se
solicita la primera copia de seguridad. Azure Backup también puede tomar una instantánea del almacenamiento
subyacente si la máquina virtual no se está ejecutando cuando se realiza la copia de seguridad.
De forma predeterminada, Azure Backup toma una copia de seguridad coherente del sistema de archivos. Después
de que el servicio Azure Backup tome la instantánea, los datos se transfieren al almacén de Recovery Services. Para
que el proceso resulte más eficaz, Azure Backup identifica y transfiere únicamente los bloques de datos que han
cambiado desde la última copia de seguridad.
Lista de puntos de recuperación disponibles

Para restaurar un disco, debe seleccionar un punto de recuperación como el origen de los datos de recuperación.
Dado que la directiva predeterminada crea un punto de recuperación cada día y lo mantiene durante 30 días,
puede mantener un conjunto de puntos de recuperación que le permita seleccionar un punto concreto a tiempo
para la recuperación.
Para ver una lista de los puntos de recuperación disponibles, use az backup recoverypoint list. El punto de
recuperación name se usa para recuperar discos. En este tutorial, queremos usar el punto de recuperación más
reciente disponible. El parámetro --query [0].name selecciona el nombre del punto de recuperación más reciente
de la siguiente manera:
az backup recoverypoint list \

--item-name myVM \
--query [0].name \
--output tsv
Restaurar un disco de máquina virtual

Para restaurar el disco desde el punto de recuperación, cree primero una cuenta de almacenamiento de Azure. Esta
cuenta de almacenamiento se usa para almacenar el disco restaurado. En pasos adicionales, el disco restaurado se
usa para crear una máquina virtual.
1. Para crear una cuenta de almacenamiento, use az storage account create. El nombre de la cuenta de
almacenamiento debe estar en minúsculas y ser único globalmente. Reemplace mystorageaccount por su
propio nombre único:
az storage account create \

--name mystorageaccount \
--sku Standard_LRS
2. Restaure el disco desde el punto de recuperación con az backup restore restore-disks. Reemplace
mystorageaccount por el nombre de la cuenta de almacenamiento que creó en el comando anterior.
Reemplace myRecoveryPointName por el nombre del punto de recuperación que obtuvo en la salida del
comando az backup recoverypoint list anterior:
az backup restore restore-disks \

--item-name myVM \
--storage-account mystorageaccount \
--rp-name myRecoveryPointName
Supervisión del trabajo de restauración

Para supervisar el estado de un trabajo de restauración, use az backup job list:
az backup job list \

--output table
El resultado es similar al ejemplo siguiente, que muestra que el estado del trabajo de restauración es InProgress:
Name Operation Status Item Name Start Time UTC Duration

-------- --------------- ---------- ----------- ------------------- --------------
7f2ad916 Restore InProgress myvm 2017-09-19T19:39:52 0:00:34.520850
a0a8e5e6 Backup Completed myvm 2017-09-19T03:09:21 0:15:26.155212
fe5d0414 ConfigureBackup Completed myvm 2017-09-19T03:03:57 0:00:31.191807
Cuando Estado del trabajo de restauración indica Completado, el disco se ha restaurado en la cuenta de
almacenamiento.
Convertir el disco restaurado en un disco administrado

El trabajo de restauración crea un disco no administrado. Para crear una máquina virtual desde el disco, debe
convertirse primero en un disco administrado.
1. Obtenga la información de conexión de la cuenta de almacenamiento con az storage account show -
connection-string. Reemplace mystorageaccount por el nombre de la cuenta de almacenamiento de la
siguiente manera:
export AZURE_STORAGE_CONNECTION_STRING=$( az storage account show-connection-string \

--output tsv \
--name mystorageaccount )
2. El disco no administrado está protegido en la cuenta de almacenamiento. Los siguientes comandos de

obtienen información acerca del disco no administrado y crean una variable denominada uri que se usa en
el paso siguiente al crear el disco administrado.
container=$(az storage container list --query [0].name -o tsv)

blob=$(az storage blob list --container-name $container --query [0].name -o tsv)
uri=$(az storage blob url --container-name $container --name $blob -o tsv)
3. Ahora puede crear un disco administrado desde el disco recuperado con disk create. La variable uri del paso
anterior se usa como origen para el disco administrado.
az disk create \
--name myRestoredDisk \
--source $uri
4. Dado que ahora tiene un disco administrado obtenido del disco restaurado, limpie el disco no administrado
y la cuenta de almacenamiento con az storage account delete. Reemplace mystorageaccount por el nombre
de la cuenta de almacenamiento de la siguiente manera:
az storage account delete \

--name mystorageaccount

El último paso es crear una máquina virtual desde el disco administrado.
1. Cree una máquina virtual desde el disco administrado con az vm create como se indica a continuación:
az vm create \
--name myRestoredVM \
--attach-os-disk myRestoredDisk \
--os-type linux
2. Para comprobar que la máquina virtual se ha creado desde el disco recuperado, enumere las máquinas
virtuales del grupo de recursos con az vm list como se indica a continuación:
az vm list --resource-group myResourceGroup --output table
Pasos siguientes
En este tutorial, ha restaurado un disco desde un punto de recuperación y, a continuación, ha creado una máquina
virtual desde el disco. Ha aprendido a:
Restaurar un disco desde un punto de recuperación
Avance hasta el siguiente tutorial para obtener información acerca de cómo restaurar archivos individuales desde
un punto de recuperación.
Restauración de archivos en una máquina virtual de Azure
Restauración de archivos en una máquina virtual de
Azure
Azure Backup crea puntos de recuperación que se almacenan en almacenes de recuperación con redundancia
geográfica. Cuando se realiza una restauración desde un punto de recuperación, se puede restaurar toda una
máquina virtual o archivos individuales. En este artículo se detalla cómo restaurar archivos individuales. En este
tutorial, aprenderá a:
Conectar un punto de recuperación a una máquina virtual
Restaurar archivos desde un punto de recuperación

local.




Si decide instalar y usar la CLI localmente, para este tutorial es preciso que ejecute la CLI de Azure versión 2.0.18 o
posterior. Ejecute az --version para encontrar la versión. Si necesita instalarla o actualizarla, consulte Instalación
de la CLI de Azure.
Requisitos previos
Para este tutorial se necesita una máquina virtual Linux protegida con Azure Backup. Para simular un proceso de
recuperación y la eliminación accidental de archivos, elimine una página desde un servidor web. Si necesita una
máquina virtual Linux que ejecute un servidor web y esté protegida con Azure Backup, consulte Copia de
seguridad de una máquina virtual en Azure con la CLI.
Cuando Azure inicia una copia de seguridad, la extensión de copia de seguridad en la máquina virtual toma una
instantánea de un momento dado. La extensión de copia de seguridad se instala en la máquina virtual cuando se
solicita la primera copia de seguridad. Azure Backup también puede tomar una instantánea del almacenamiento
subyacente si la máquina virtual no se está ejecutando cuando se realiza la copia de seguridad.
De forma predeterminada, Azure Backup toma una copia de seguridad coherente del sistema de archivos. Después
de que el servicio Azure Backup tome la instantánea, los datos se transfieren al almacén de Recovery Services. Para
que el proceso resulte más eficaz, Azure Backup identifica y transfiere únicamente los bloques de datos que han
cambiado desde la última copia de seguridad.
Eliminación de un archivo de una máquina virtual

Si elimina un archivo o realiza cambios en un archivo accidentalmente, puede restaurar archivos individuales
desde un punto de recuperación. Este proceso permite examinar los archivos de los que se ha realizado una copia
de seguridad en un punto de recuperación y restaurar solo los archivos necesarios. En este ejemplo, se elimina un
archivo de un servidor web para demostrar el proceso de recuperación de nivel de archivo.
1. Para conectarse a su máquina virtual, obtenga su dirección IP con az vm show:
az vm show --resource-group myResourceGroup --name myVM -d --query [publicIps] --o tsv
2. Para comprobar que el sitio web funciona actualmente, abra un explorador web en la dirección IP pública de
la máquina virtual. Deje abierta la ventana del explorador web.
3. Conéctese a la máquina virtual mediante SSH. Reemplace publicIpAddress por la dirección IP pública que
obtuvo en un comando anterior:
ssh publicIpAddress
4. Elimine la página predeterminada del servidor web en /var/www/html/index.nginx-debian.html como se

indica a continuación:
sudo rm /var/www/html/index.nginx-debian.html
5. En el explorador web, actualice la página web. El sitio web ya no carga la página, tal como se muestra en el
ejemplo siguiente:
6. Cierre la sesión de SSH de la máquina virtual de la manera siguiente:
exit
Generar un script de recuperación de archivos

Para restaurar sus archivos, Azure Backup proporciona un script que se ejecuta en la máquina virtual y que conecta
el punto de recuperación como una unidad local. Puede examinar esta unidad local, restaurar archivos en la propia
máquina virtual y, a continuación, desconectar el punto de recuperación. Azure Backup continúa realizando la copia
seguridad de los datos de acuerdo con la directiva de retención y programación asignada.
1. Para enumerar los puntos de recuperación de la máquina virtual, use az backup recoverypoint list. En este
ejemplo, se selecciona el punto de recuperación más reciente de la máquina virtual denominada myVM que
está protegida en myRecoveryServicesVault:
az backup recoverypoint list \

--item-name myVM \
--query [0].name \
--output tsv
2. Para obtener el script que conecta el punto de recuperación a la máquina virtual o lo monta en esta, use az
backup restore files mount-rp. En el ejemplo siguiente se obtiene el script de la máquina virtual
denominada myVM que está protegida en myRecoveryServicesVault.
Reemplace myRecoveryPointName por el nombre del punto de recuperación que obtuvo en el comando
anterior:
az backup restore files mount-rp \
--item-name myVM \
El script se descarga y se muestra una contraseña, como en el ejemplo siguiente:
File downloaded: myVM_we_1571974050985163527.sh. Use password c068a041ce12465
3. Para transferir el script a la máquina virtual, use Secure Copy (SCP ). Proporcione el nombre del script
descargado y reemplace publicIpAddress por la dirección IP pública de la máquina virtual. Asegúrese de
incluir el signo : final al final del comando SCP como se indica a continuación:
scp myVM_we_1571974050985163527.sh 52.174.241.110:
Restaurar archivos en la máquina virtual

Con el script de recuperación copiado en la máquina virtual, ahora puede conectar el punto de recuperación y
restaurar archivos.
1. Conéctese a la máquina virtual mediante SSH. Reemplace publicIpAddress por la dirección IP pública de la
máquina virtual, como se indica a continuación:
ssh publicIpAddress
2. Para permitir que el script se ejecute correctamente, agregue permisos con chmod. Escriba el nombre de su
propio script:
chmod +x myVM_we_1571974050985163527.sh
3. Para montar el punto de recuperación, ejecute el script. Escriba el nombre de su propio script:
./myVM_we_1571974050985163527.sh
Cuando se ejecute el script, se le pedirá que escriba una contraseña para acceder al punto de recuperación.
Escriba la contraseña que se muestra en la salida del comando az backup restore files mount-rp anterior
que generó el script de recuperación.
La salida del script proporciona la ruta de acceso del punto de recuperación. La siguiente salida de ejemplo
muestra que el punto de recuperación está montado en /home/azureuser/myVM -
20170919213536/Volume1:
Microsoft Azure VM Backup - File Recovery
______________________________________________
Please enter the password as shown on the portal to securely connect to the recovery point. :
c068a041ce12465
Connecting to recovery point using ISCSI service...
Connection succeeded!
Please wait while we attach volumes of the recovery point to this machine...
************ Volumes of the recovery point and their mount paths on this machine ************
Sr.No. | Disk | Volume | MountPath
1) | /dev/sdc | /dev/sdc1 | /home/azureuser/myVM-20170919213536/Volume1
************ Open File Explorer to browse for files. ************
4. Use cp para volver a copiar la página web predeterminada de NGINX del punto de recuperación montado a
la ubicación del archivo original. Reemplace el punto de montaje /home/azureuser/myVM -
20170919213536/Volume1 por su propia ubicación:
sudo cp /home/azureuser/myVM-20170919213536/Volume1/var/www/html/index.nginx-debian.html /var/www/html/
5. En el explorador web, actualice la página web. El sitio web se vuelve a cargar ahora correctamente, tal como
se muestra en el ejemplo siguiente:
6. Cierre la sesión de SSH de la máquina virtual de la manera siguiente:
exit
7. Desmonte el punto de recuperación de su máquina virtual con az backup restore files unmount-rp. En el
ejemplo siguiente se desmonta el punto de recuperación de la máquina virtual denominada myVM en
myRecoveryServicesVault.
Reemplace myRecoveryPointName por el nombre del punto de recuperación que obtuvo en los comandos
anteriores:
az backup restore files unmount-rp \
--item-name myVM \
Pasos siguientes
En este tutorial, conectó un punto de recuperación a una máquina virtual y restauró los archivos de un servidor
web. Ha aprendido a:
Conectar un punto de recuperación a una máquina virtual
Restaurar archivos desde un punto de recuperación
Avance al siguiente tutorial para obtener información acerca de cómo realizar copias de seguridad de Windows
Server en Azure.
Hacer copias de seguridad de Windows Server en Azure
Acerca de Site Recovery
¡ Bienvenido al servicio Azure Site Recovery! En este artículo se ofrece una rápida información general del
servicio.
Como organización, necesita adoptar una estrategia de continuidad empresarial y de recuperación ante desastres
(BCDR ) que mantenga sus datos seguros, y sus aplicaciones y cargas de trabajo en pleno funcionamiento cuando
se produzcan interrupciones planeadas o imprevistas.
Azure Recovery Services colabora con su estrategia de BCDR:
Servicio Site Recovery: Site Recovery ayuda a garantizar la continuidad empresarial manteniendo las
aplicaciones y cargas de trabajo empresariales en funcionamiento durante las interrupciones. Site Recovery
replica las cargas de trabajo que se ejecutan en máquinas físicas y virtuales desde un sitio principal a una
ubicación secundaria. Cuando se produce una interrupción en el sitio principal, se conmuta por error a la
ubicación secundaria y se accede desde allí a las aplicaciones. Cuando la ubicación principal vuelva a estar en
ejecución, puede realizar la conmutación por recuperación en ella.
Servicio Backup: el servicio Azure Backup mantiene los datos seguros y recuperables, ya que realiza copias
de seguridad de los mismos en Azure.
Site Recovery puede administrar la replicación de:
Máquinas virtuales de Azure que se replican entre regiones de Azure.
Máquinas virtuales locales, máquinas virtuales de Azure Stack y servidores físicos.
¿Qué ofrece Site Recovery?

CARACTERÍSTICA DETALLES
Solución de BCDR simple Mediante Site Recovery se pueden configurar y administrar la

replicación, la conmutación por error y la conmutación por
recuperación desde una sola ubicación en Azure Portal.
Replicación de máquinas virtuales de Azure Puede configurar la recuperación ante desastres de máquinas
virtuales de Azure de una región primaria a una secundaria.
Replicación de máquinas virtuales local Las máquinas virtuales y los servidores físicos se pueden
replicar en Azure o en un centro de datos local secundario. Si
se replican en Azure, se elimina el costo y la complejidad de
mantener un centro de datos secundario.
Replicación de la carga de trabajo La replicación de cualquier carga de trabajo que se ejecuta en

máquinas virtuales de Azure compatibles, máquinas virtuales
de Hyper-V y VMware locales y servidores físicos Windows o
Linux.
Resistencia de datos Site Recovery coordina la replicación sin interceptar los datos
de las aplicaciones. Cuando se realiza la replicación en Azure,
los datos se almacenan en Azure Storage con toda la
resistencia que proporciona. Cuando se produce la
conmutación por error, las máquinas virtuales de Azure en
función de los datos replicados.
CARACTERÍSTICA DETALLES
Destinos RTO y el RPO Mantenga los objetivos de tiempo de recuperación (RTO) y

los objetivos de punto de recuperación (RPO) dentro de los
límites de la organización. Site Recovery proporciona una
replicación continua tanto a las máquinas virtuales de Azure
como a las máquinas virtuales VMware con una frecuencia de
tan solo 30 segundos para Hyper-V. Para reducir aún más el
RTO, realice la integración con Azure Traffic Manager.
Mantener la coherencia de aplicaciones a través de la Puede realizar la replicación mediante puntos de

conmutación por error configuración con instantáneas coherentes con la aplicación.
Estas instantáneas capturan los datos del disco, todos los
datos en que hay en la memoria y todas las transacciones en
curso.
Pruebas sin interrupciones Puede ejecutar fácilmente maniobras de recuperación ante

desastres, sin que ello afecte a la replicación en curso.
Conmutaciones por error flexibles Puede ejecutar conmutaciones por error planeadas para
interrupciones planeadas sin pérdida de datos o
conmutaciones por error no planeadas con una pérdida de
datos mínima (según la frecuencia de replicación) ante
desastres inesperados. Puede conmutar por recuperación a
su sitio principal fácilmente cuando vuelva a estar disponible.
Planes de recuperación personalizados Con los planes de recuperación, puede personalizar y

secuenciar la conmutación por error y la recuperación de
aplicaciones de niveles múltiples en varias máquinas virtuales.
Puede agrupar las máquinas en un plan de recuperación y,
opcionalmente, agregar scripts y acciones manuales. Los
planes de recuperación se pueden integrar con runbooks de
Azure Automation.
Integración de BCDR Site Recovery se integra con otras tecnologías de BCDR. Por
ejemplo, puede utilizar Site Recovery para proteger el back-
end de SQL Server de cargas de trabajo corporativas, con
compatibilidad nativa para SQL Server AlwaysOn, a fin de
administrar la conmutación por error de grupos de
disponibilidad.
Integración de Azure Automation Una ingente biblioteca de Azure Automation proporciona

scripts específicos de la aplicación y preparados para la
producción que se pueden descargar e integrarse con Site
Recovery.
Integración de red Site Recovery se integra con Azure para simplificar la

administración de la red de una aplicación, lo que incluye la
reserva de direcciones IP, la configuración de equilibradores
de carga o la integración de Azure Traffic Manager, con el fin
de que los cambios de red sean eficientes.
¿Qué puedo replicar?

COMPATIBLE DETALLES
COMPATIBLE DETALLES
Escenarios de replicación Replique las máquinas virtuales de Azure de una región de

Azure a otra.
Replique las máquinas virtuales de VMware locales, las

máquinas virtuales de Hyper-V, los servidores físicos
(Windows y Linux) y las máquinas de virtuales Azure Stack en
Azure.
Replique las instancias de Windows de AWS a Azure.
Replique las máquinas virtuales locales de VMware, de

Hyper-V administradas por System Center VMM y los
servidores físicos en un sitio secundario.
Regiones Revise las regiones admitidas para Site Recovery.
Máquinas replicadas Revise los requisitos de la replicación de máquinas virtuales

de Azure, máquinas virtuales y servidores físicos de VMware
locales y los máquinas virtuales de Hyper-V locales.
Cargas de trabajo Puede replicar cualquier carga de trabajo que se ejecute en

una máquina que se admita para la replicación. Además, el
equipo de Site Recovery ha realizado pruebas específicas para
diversas aplicaciones.
Pasos siguientes
Más información sobre la compatibilidad con cargas de trabajo.
Empiece a trabajar con la replicación de máquina virtual de Azure entre regiones.
Configuración de la recuperación ante desastres de
máquinas virtuales de Azure
El servicio Azure Site Recovery contribuye a su estrategia de recuperación ante desastres mediante la
administración y la coordinación de la replicación, la conmutación por error y la conmutación por recuperación de
máquinas locales y máquinas virtuales (VM ) de Azure.
Este tutorial muestra cómo configurar la recuperación ante desastres en máquinas virtuales de Azure replicándolas
de una región de Azure a otra. En este tutorial, aprenderá a:
Comprobación de la configuración de los recursos de destino
Configuración de la conectividad de red saliente para máquinas virtuales
Habilitación de la replicación para una máquina virtual
NOTE
En este artículo se proporcionan instrucciones para implementar la recuperación ante desastres con la configuración más
sencilla. Si desea obtener información acerca de la configuración personalizada, consulte los artículos de esta sección.
Requisitos previos
Para completar este tutorial:
Revise la arquitectura del escenario y sus componentes.
Revise los requisitos de compatibilidad antes de empezar.

Cree el almacén en cualquier región, excepto en la de origen.
1. Inicie sesión en Azure Portal > Recovery Services.
2. En el menú de Azure Portal o en la página principal, seleccione Crear un recurso. Después, seleccione
Herramientas de administración > Backup and Site Recovery.
3. En Nombre, especifique un nombre descriptivo para identificar el almacén. Si tiene más de una suscripción,
seleccione la apropiada.
4. Cree un grupo de recursos o seleccione uno existente. Especifique una región de Azure. Para comprobar las
regiones admitidas, consulte la disponibilidad geográfica en Detalles de precios de Azure Site Recovery.
5. Para acceder rápidamente al almacén desde el panel, haga clic en Anclar al panel y, después, en Crear.
El nuevo almacén se agrega al Panel, en Todos los recursos, y en la página principal Almacenes de
Recovery Services.
Comprobación de la configuración de los recursos de destino

1. Compruebe que su suscripción de Azure permite crear máquinas virtuales en la región de destino. Para habilitar
la cuota necesaria, póngase en contacto con el soporte técnico.
2. Asegúrese de que su suscripción tiene suficientes recursos para admitir tamaños de máquinas virtuales que se
correspondan con las máquinas virtuales de origen. Site Recovery elige el mismo tamaño para la máquina
virtual de destino o el más cercano posible.
Configuración de la conectividad de red saliente para máquinas

virtuales
Para que Site Recovery funcione de la forma esperada, debe modificar la conectividad de red de salida de las
máquinas virtuales que desee replicar.
NOTE
Site Recovery no admite el uso de un proxy de autenticación para controlar la conectividad de la red.
Conectividad de salida para las direcciones URL

Si usa un proxy de firewall basado en dirección URL para controlar la conectividad de salida, debe permitir acceder
a estas direcciones URL.
URL DETALLES
* .blob.core.windows.net Permite que los datos se puedan escribir desde la máquina

virtual a la cuenta de almacenamiento de caché en la región
de origen.
URL DETALLES
login.microsoftonline.com Proporciona autorización y autenticación de las direcciones

URL del servicio Site Recovery.
*.hypervrecoverymanager.windowsazure.com Permite que la máquina virtual se comunique con el servicio

Site Recovery.
*.servicebus.windows.net Permite que la máquina virtual escriba los datos de

diagnóstico y supervisión de Site Recovery.
Conectividad de salida para rangos de direcciones IP

Si desea controlar la conectividad de salida mediante direcciones IP, en lugar de direcciones URL, permita dichas
direcciones en los firewalls basados en IP, el proxy o las reglas del grupo de seguridad de red.
Intervalos de direcciones IP del centro de datos de Microsoft Azure
Intervalos de direcciones IP del centro de datos de Windows Azure en Alemania
Intervalos de direcciones IP del centro de datos de Windows Azure en China
Direcciones URL e intervalos de direcciones IP de Office 365
Direcciones IP de puntos de conexión del servicio Site Recovery
Si usa NSG, puede crear reglas de NSG de etiquetas de servicio de almacenamiento para la región de origen. Más
información.
Comprobación de los certificados de la máquina virtual de Azure

Compruebe que las máquinas virtuales que desea replicar tienen los certificados raíz más recientes. Si nos los
tienen, la máquina virtual no se puede registrar en Site Recovery debido a las restricciones de seguridad.
Para las máquinas virtuales de Windows, instale las actualizaciones de Windows más recientes en la máquina
virtual, de modo que todos los certificados raíz de confianza estén en ella. En un entorno desconectado, siga los
procesos estándar de actualización de certificados y de Windows Update en su organización.
En las máquinas virtuales Linux, para obtener los certificados raíz de confianza y la lista de revocación de
certificados en la máquina virtual, siga las instrucciones proporcionadas por su distribuidor de Linux.
Obtención de permisos en la cuenta

Azure Site Recovery proporciona tres roles integrados para controlar las operaciones de administración de Site
Recovery.
Colaborador de Site Recovery: este rol tiene todos los permisos necesarios para administrar las
operaciones de Azure Site Recovery en un almacén de Recovery Services. Sin embargo, un usuario con este
rol no puede crear ni eliminar un almacén de Recovery Services, ni tampoco asignar derechos de acceso a
otros usuarios. Este rol es ideal para administradores de recuperación ante desastres que pueden habilitar y
administrar la recuperación ante desastres para aplicaciones u organizaciones completas.
Operador de Site Recovery: este rol tiene permisos para ejecutar y administrar operaciones de
conmutación por error y por recuperación. Un usuario con este rol no puede habilitar ni deshabilitar la
replicación, crear ni eliminar almacenes, registrar una nueva infraestructura ni asignar derechos de acceso a
otros usuarios. Este rol es ideal para un operador de recuperación ante desastres que puede conmutar por
error desde máquinas virtuales o aplicaciones cuando se lo indican los propietarios de las aplicaciones y los
administradores de TI. Tras la resolución del desastre, el operador de recuperación ante desastres puede
volver a proteger las máquinas virtuales y realizar la conmutación por recuperación.
Lector de Site Recovery: este rol tiene permisos para ver todas las operaciones de administración de Site
Recovery. Este rol es ideal para un ejecutivo de supervisión de TI que puede supervisar el estado actual de
protección y crear vales de soporte.
Obtenga más información sobre los roles integrados de Azure RBAC.
Habilitación de la replicación para una máquina virtual

Seleccione el origen
1. En los almacenes de Recovery Services, haga clic en el nombre del almacén y > +Replicar.
2. En Origen, seleccione Azure.
3. En Ubicación de origen, seleccione la región de Azure de origen donde se ejecutan actualmente sus
4. Seleccione la suscripción de origen donde se ejecutan las máquinas virtuales. Puede tratarse de cualquier
suscripción dentro del mismo inquilino de Azure Active Directory donde exista el almacén de Recovery
Services.
5. Seleccione el grupo de recursos de origen y haga clic en Aceptar para guardar la configuración.
Seleccione las máquinas virtuales

Site Recovery recupera una lista de las máquinas virtuales asociadas a la suscripción y el servicio en la nube/grupo
de recursos.
1. En Máquinas virtuales, seleccione las máquinas virtuales que quiere replicar.
2. Haga clic en OK.
Configuración de las opciones de replicación
Site Recovery crea la configuración predeterminada y la directiva de replicación para la región de destino. La
configuración se puede cambiar cuando sea necesario.
1. Haga clic en Configuración para ver la configuración de destino y de replicación.
2. Para invalidar la configuración de destino predeterminada, haga clic en Personalizar junto a Grupo de
recursos, red, almacenamiento y disponibilidad.
3. Personalice la configuración del destino como se resume en la tabla.
CONFIGURACIÓN DETALLES
Suscripción de destino De forma predeterminada, la suscripción de destino será la

misma que la de origen. Haga clic en "Personalizar" para
seleccionar una suscripción de destino diferente dentro del
mismo inquilino de Azure Active Directory.
Ubicación de destino la región de destino que se usa para la recuperación ante

desastres.
Se recomienda que la ubicación de destino coincida con la

ubicación del almacén de Site Recovery.
Grupo de recursos de destino el grupo de recursos en la región de destino que contiene

las máquinas virtuales de Azure después de la
conmutación por error.
De forma predeterminada, Site Recovery crea un nuevo

grupo de recursos en la región de destino con un sufijo
"asr". La ubicación del grupo de recursos de destino puede
ser cualquier región, excepto la región en la que se
hospedan las máquinas virtuales de origen.
Red virtual de destino la red en la región de destino en la que las máquinas

virtuales se encuentran después de la conmutación por
error.
De forma predeterminada, Site Recovery crea una nueva

red (y subredes) virtual en la región de destino con un
sufijo "asr".
Cuentas de almacenamiento en caché Site Recovery utiliza una cuenta de almacenamiento en la

región de origen. Los cambios en las máquinas virtuales de
origen se envían a esta cuenta, antes de la replicación en la
ubicación de destino.
Si usa la cuenta de almacenamiento en caché con firewall

habilitado, asegúrese de habilitar Permitir servicios de
Microsoft de confianza. Más información.
Cuentas de almacenamiento de destino (si la máquina de forma predeterminada, Site Recovery crea una nueva
virtual de origen no usa discos administrados) cuenta de almacenamiento en la región de destino para
reflejar la cuenta de almacenamiento de la máquina virtual
de origen.
Si usa la cuenta de almacenamiento en caché con firewall

habilitado, habilite Permitir servicios de Microsoft de
confianza.
Discos administrados de réplica (si la máquina virtual de forma predeterminada, Site Recovery crea discos
de origen usa discos administrados) administrados de réplica en la región de destino para
reflejar los discos administrados de la máquina virtual de
origen con el mismo tipo de almacenamiento (Standard o
Premium) que el disco administrado de la máquina virtual
de origen. Solo se puede personalizar el tipo de disco
Conjuntos de disponibilidad de destino de forma predeterminada, Azure Site Recovery crea un

conjunto de disponibilidad en la región de destino con un
nombre con el sufijo "asr" para la parte de máquina virtual
de un conjunto de disponibilidad de la región de origen. En
caso de que el conjunto de disponibilidad que cree Azure
Site Recovery ya exista, se vuelve a usar.
Zonas de disponibilidad de destino de forma predeterminada, Site Recovery asigna el mismo

número de zona que la región de origen en la región de
destino si esta admite zonas de disponibilidad.
Si la región de destino no admite zonas de disponibilidad,

las máquinas virtuales de destino se configurarán como
instancias únicas de forma predeterminada.
Haga clic en Personalizar para configurar las máquinas

virtuales como parte de un conjunto de disponibilidad en
la región de destino.
No puede cambiar el tipo de disponibilidad (instancia

única, zona de disponibilidad o conjunto de disponibilidad)
después de habilitar la replicación. Tendrá que deshabilitar
y habilitar la replicación para cambiar el tipo de
disponibilidad.
4. Para personalizar la configuración de la directiva de replicación, haga clic en Personalizar junto a Directiva
de replicación y modifique los siguientes valores según sea necesario.
Nombre de la directiva de replicación nombre de la directiva.
Retención de punto de recuperación de forma predeterminada, Site Recovery conserva los

puntos de recuperación durante 24 horas. Puede
configurar un valor entre 1 y 72 horas.
Frecuencia de las instantáneas coherentes con la de forma predeterminada, Site Recovery toma una
aplicación instantánea coherente con la aplicación cada 4 horas.
Puede configurar cualquier valor entre 1 y 12 horas.
Una instantánea coherente con la aplicación es una

instantánea en un momento dado de los datos de la
aplicación dentro de la máquina virtual. El Servicio de
instantáneas de volumen (VSS) garantiza que la aplicación
en la máquina virtual se encuentre en un estado coherente
cuando se toma la instantánea.
Grupo de replicación si la aplicación necesita coherencia de múltiples máquinas

virtuales entre varias máquinas virtuales, puede crear un
grupo de replicación para estas máquinas virtuales. De
forma predeterminada, las máquinas virtuales
seleccionadas no forman parte de ningún grupo de
replicación.
5. En Personalizar, seleccione Sí para lograr coherencia entre varias máquinas virtuales si desea agregar
máquinas virtuales a un grupo de replicación nuevo o existente. A continuación, haga clic en Aceptar.
NOTE
Todas las máquinas de un grupo de replicación tendrán puntos de recuperación compartidos coherentes con los
bloqueos y coherentes con la aplicación cuando conmutan por error.
La habilitación de la coherencia entre varias VM puede afectar al rendimiento de la carga de trabajo (consume
mucha CPU). Debe usarse únicamente si las máquinas ejecutan la misma carga de trabajo y necesita coherencia
entre varias máquinas.
Puede tener un máximo de 16 máquinas virtuales en un grupo de replicación.
Si habilita la coherencia entre varias máquinas virtuales, las máquinas del grupo de replicación se comunican entre
sí a través del puerto 20004. Asegúrese de que no haya ningún firewall que bloquee la comunicación interna entre
las máquinas virtuales en este puerto.
Para las máquinas virtuales de Linux de un grupo de replicación, asegúrese de que el tráfico saliente en el puerto
20004 se abra manualmente según la guía de la versión de Linux.
Configuración de los valores del cifrado

Si la máquina virtual de origen tiene habilitado Azure Disk Encryption (ADE ), revise la configuración.
1. Compruebe la configuración:
Almacenes de claves de cifrado de disco: De forma predeterminada, Site Recovery crea un almacén
de claves en las claves de cifrado de disco de la máquina virtual de origen con un sufijo "asr". Si ya existe
el almacén de claves, se vuelve a usar.
Almacenes de claves de cifrado de claves: De forma predeterminada, Site Recovery crea un nuevo
almacén de claves en la región de destino. El nombre tiene un sufijo "asr" y se basa en las claves de
cifrado de claves de la máquina virtual de origen. Si el almacén de claves que ha creado Site Recovery ya
existe, se vuelve a usar.
2. Haga clic en Personalizar para seleccionar los almacenes de claves personalizados.
NOTE
Actualmente, Azure Site Recovery solo admite máquinas virtuales Azure con sistemas operativos Windows y que estén
habilitadas para el cifrado con la aplicación de Azure AD.
Seguimiento del estado de replicación
1. En Configuración, haga clic en Actualizar para obtener el estado más reciente.
2. Realice un seguimiento de estado y progreso como se indica a continuación:
Realice un seguimiento del progreso del trabajo Habilitar protección en Configuración > Trabajos >
Trabajos de Site Recovery.
En Configuración > Elementos replicados, puede ver el estado de las máquinas virtuales y el
progreso inicial de la replicación. Haga clic en la máquina virtual para ir a los detalles de su
configuración.
Pasos siguientes
En este tutorial se configuró la recuperación ante desastres para una máquina virtual de Azure. Ya puede iniciar la
exploración de la recuperación ante desastres para comprobar que la conmutación por error funciona como cabría
esperar.
Exploración de la recuperación ante desastres
Ejecución de un simulacro de recuperación ante
desastres en máquinas virtuales de Azure de una
región secundaria de Azure
El servicio Azure Site Recovery contribuye a la estrategia de recuperación ante desastres y continuidad
empresarial (BCDR ) al mantener sus aplicaciones empresariales al día y disponibles durante interrupciones
planeadas y no planeadas. Azure Site Recovery administra y coordina la recuperación ante desastres de máquinas
locales y máquinas virtuales de Azure, lo que incluye la replicación, la conmutación por error y la recuperación.
En este tutorial se muestra cómo ejecutar una exploración de recuperación ante desastres en una máquina virtual
de Azure, desde una región de Azure a otra, con una conmutación por error de prueba. Mediante una exploración
se valida su estrategia de replicación sin ocasionar ninguna pérdida de datos ni tiempo de inactividad, y sin afectar
al entorno de producción. En este tutorial, aprenderá a:
Comprobar los requisitos previos
Ejecutar una conmutación por error de prueba en una sola máquina virtual
NOTE
Este tutorial le ayuda a realizar un simulacro de recuperación ante desastres con los pasos mínimos; en caso de que desee
obtener más información acerca de los diversos aspectos asociados con la realización del simulacro, incluidas las
consideraciones de red, la automatización o la solución de problemas, consulte los documentos de procedimientos para las
Requisitos previos
Antes de ejecutar una conmutación por error de prueba, se recomienda que compruebe las propiedades de la
máquina virtual para asegurarse de que todo se ajusta a lo esperado. Acceda a las propiedades de la máquina
virtual en Elementos replicados. En la hoja Información esencial se detalla la configuración y el estado de
las máquinas.
Se recomienda usar una red de máquina virtual de Azure independiente en la conmutación por error
de prueba en lugar de la red predeterminada que se configuró cuando habilitó la replicación.
Según las configuraciones de la red de origen de cada NIC, puede especificar de forma opcional una subred,
dirección IP, dirección IP pública, grupo de seguridad de red o equilibrador de carga interno para
asociar a cada NIC en la configuración de la conmutación por error de prueba en Proceso y red antes de
realizar el simulacro de recuperación ante desastres.
Ejecución de una conmutación por error de prueba

1. En Configuración > Elementos replicados, haga clic en la VM > icono +Probar conmutación por
error.
2. En Conmutación por error, seleccione el punto de recuperación que usar para la conmutación por error:
Más reciente: procesa todos los datos en el servicio Site Recovery y proporciona el objetivo de tiempo
de recuperación (RTO ) más bajo.
Procesado más recientemente: conmuta por error la máquina virtual en el último punto de
recuperación procesado por Site Recovery. Se muestra la marca de tiempo. Con esta opción, no se
emplea tiempo en el procesamiento de datos, por lo que se proporciona un objetivo de tiempo de
recuperación (RTO ) bajo.
Más reciente coherente con la aplicación: esta opción conmuta por error todas las VM en el punto
de recuperación más reciente coherente con la aplicación. Se muestra la marca de tiempo.
Personalizado: conmuta por error a un punto de recuperación concreto. La personalización solo está
disponible cuando se conmuta por error una sola máquina virtual y no para la conmutación por error
con un plan de recuperación.
3. Seleccione la red virtual de Azure de destino a la se conectarán las VM de Azure en la región secundaria
después de que se produzca la conmutación por error.
NOTE
La lista desplegable para seleccionar la red virtual de Azure no estará visible si la configuración de conmutación por
error de prueba está preconfigurada para el elemento replicado.
4. Para iniciar la conmutación por error, haga clic en Aceptar. Para realizar el seguimiento del progreso, haga
clic en la máquina virtual para abrir sus propiedades. También puede hacer clic en el trabajo Conmutación
por error de prueba en el nombre del almacén > Configuración > Trabajos > Trabajos de Site
Recovery.
5. Una vez finalizada la conmutación por error, la VM de Azure de réplica aparece en Azure Portal > Virtual
Machines. Asegúrese de que la máquina virtual está en funcionamiento, tiene el tamaño adecuado y está
conectada a la red apropiada.
6. Para eliminar las máquinas virtuales que se crearon durante la conmutación por error de prueba, haga clic
en Cleanup test failover (Limpiar conmutación por error de prueba) en el artículo replicado o el plan de
recuperación. En Notas, registre y guarde las observaciones asociadas a la conmutación por error de
prueba.
Pasos siguientes
Ejecutar una conmutación por error de producción
Conmutación por error y reprotección de máquinas
virtuales de Azure entre regiones
En este tutorial se describe cómo conmutar por error una máquina virtual (VM ) de Azure en una región secundaria
de Azure con el servicio Azure Site Recovery. Una vez realizada la conmutación por error, volverá a proteger la
máquina virtual. En este tutorial, aprenderá a:
Conmutar por error la máquina virtual de Azure
Volver a proteger la máquina virtual de Azure secundaria, de modo que se replique en la región principal.
NOTE
Este tutorial describe la ruta más sencilla, con las opciones predeterminadas y la mínima personalización. Para escenarios más
complejos, use los artículos de Guías de procedimientos para máquinas virtuales de Azure.
Requisitos previos
Antes de empezar, repase las preguntas más frecuentes sobre la conmutación por error.
Asegúrese de que ha completado una exploración de la recuperación ante desastres para comprobar que todo
funciona según lo previsto.
Compruebe las propiedades de la máquina virtual antes de ejecutar la conmutación por error de prueba. La
máquina virtual debe cumplir los requisitos de Azure.
Ejecución de una conmutación por error en la región secundaria

1. En Elementos replicados, seleccione la máquina virtual que desea conmutar por error > Conmutar por
error
2. En Conmutación por error, seleccione un Punto de recuperación en el que realizar la conmutación por
error. Puede seleccionar una de las siguientes opciones:
Latest (Más reciente) (valor predeterminado): procesa todos los datos en el servicio Site Recovery y
proporciona el objetivo de punto de recuperación (RPO ) más bajo.
Procesado más recientemente: revierte la máquina virtual al punto de recuperación más reciente que
el servicio Site Recovery haya procesado.
Personalizado: conmuta por error a un punto de recuperación concreto. Esta opción es útil para realizar
una conmutación por error de prueba.
3. Seleccione Apague la máquina antes de comenzar con la conmutación por error si desea que Site
Recovery intente apagar las máquinas virtuales de origen antes de desencadenar la conmutación por error.
La operación de apagado ayuda a garantizar que no se pierden datos. La conmutación por error continúa
aunque se produzca un error de cierre. Site Recovery no es un origen limpio después de la conmutación por
error.
4. Siga el progreso de la conmutación por error en la página Trabajos.
5. Después de la conmutación por error, valide la máquina virtual iniciando sesión en ella. Si desea volver a
otro punto de recuperación para la máquina virtual, puede usar la opción Cambiar punto de
recuperación.
6. Realice la acción Confirmar una vez que quede satisfecho con la conmutación por error de la máquina
virtual. Al confirmar, se eliminan todos los puntos de recuperación disponibles con el servicio. Ahora no
podrá cambiar el punto de recuperación.
NOTE
Cuando se conmuta por error una máquina virtual a la que agrega un disco después de habilitar la replicación para la
máquina virtual, los puntos de la replicación mostrarán los discos que están disponibles para la recuperación. Por ejemplo, si
una máquina virtual tiene un único disco y agrega uno nuevo, los puntos de replicación que se crearon antes de agregar el
disco mostrarán que el punto de replicación se compone de "1 de 2 discos".
Volver a proteger la máquina virtual secundaria
Después de la conmutación por error de la máquina virtual, debe volver a protegerla para que se replique de
nuevo en la región principal.
1. Asegúrese de que la máquina virtual está en el estado Conmutación por error confirmada y compruebe
que la región principal está disponible, y puede crear y tener acceso a los recursos nuevos en ella.
2. En Almacén > Elementos replicados, haga clic con el botón derecho en la máquina virtual que ha sido
objeto de la conmutación por error y seleccione Volver a proteger.
3. Compruebe que la dirección de la protección, de la región secundaria a la primaria, ya está seleccionada.

4. Revise la información de Grupo de recursos, red, almacenamiento y conjuntos de disponibilidad. Los
recursos marcados se crean como parte de la operación de reprotección.
5. Haga clic en Aceptar para desencadenar un trabajo de repetición de la protección. Este trabajo inicializa el
sitio de destino con los datos más recientes. A continuación, replica las diferencias en la región principal. La
máquina virtual está ahora en un estado protegido.
Pasos siguientes
Después de la reprotección, obtenga información sobre cómo conmutar por recuperación a la región primaria
cuando esté disponible.
Obtenga más información sobre el flujo de reprotección.
Descripción de uso de máquinas virtuales de Azure
Mediante el análisis de los datos de uso de Azure, es posible obtener información importante sobre el consumo, es
decir, información que puede permitirle mejorar la asignación y administración de los costos en toda la
organización. En este documento se profundiza en los detalles de consumo de Azure Compute. Para más detalles
sobre el uso general de Azure, navegue a Descripción de la factura.
Descarga de los detalles de uso

Para comenzar, descargue los detalles de uso. En la tabla siguiente se proporciona la definición y valores de
ejemplo de uso de las máquinas virtuales implementadas a través de Azure Resource Manager. Este documento no
contiene información detallada de las máquinas virtuales implementadas a través del modelo clásico.
FIELDS SIGNIFICADO VALORES DE EJEMPLO
Fecha de uso La fecha en que se usó el recurso. "23/11/2017"
Id. de medidor Identifica el servicio de nivel superior al "Máquinas virtuales"

que pertenece este uso.
Subcategoría de medidor El identificador del medidor facturado. "2005544f-659d-49c9-9094-

Si desea conocer el uso de las 8e0aea1be3a5"
horas de proceso, existe un
medidor para cada tamaño de
máquina virtual + SO (Windows,
no Windows) + región.
Si desea conocer el uso de
software Premium, existe un
medidor para cada tipo de
software. La mayoría de las
imágenes de software Premium
tienen distintos medidores para
cada tamaño de núcleo. Para
más información, visite la página
de precios de Compute.
Nombre de medidor Es específico para cada servicio de "Horas de proceso"

Azure. En el caso de Compute, siempre
es "Horas de proceso".
Medidor de la región Identifica la ubicación del centro de "Este de Japón"

datos para ciertos servicios cuyos
precios se establecen según la ubicación
del centro de datos.
Unidad Identifica la unidad en que se cobra el "Horas"

servicio. Los recursos de Compute se
facturan por hora.
Consumida La cantidad del recurso consumida "1", "0.5"

durante ese día. Para Compute, se
facturará por cada minuto de ejecución
de la máquina virtual durante una hora
determinada (hasta seis decimales de
precisión).
Ubicación del recurso Identifica el centro de datos donde se "Este de Japón"

está ejecutando el recurso.
Servicio consumido El servicio de la plataforma Azure que "Microsoft.Compute"

ha usado.
Grupo de recursos El grupo de recursos en el que se "MyRG"

ejecuta el recurso implementado. Para
más información, consulte Información
general de Azure Resource Manager.
Id. de instancia Identificador del recurso. El identificador "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-

contiene el nombre especificado para el xxxxxxxxxxxx/
recurso cuando se creó En el caso de las resourceGroups/MyRG/providers/Micro
máquinas virtuales, el identificador de soft.Compute/virtualMachines/MyVM1"
instancia contendrá los valores
SubscriptionId, ResourceGroupName y o
VMName (o el nombre del conjunto de
escalado para el uso de conjunto de "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
escalado). xxxxxxxxxxxx/
resourceGroups/MyRG/providers/Micro
soft.Compute/virtualMachineScaleSets/
MyVMSS1"
Etiquetas Etiqueta asignada al recurso. Use "

etiquetas para agrupar los registros de {"myDepartment":"RD","myUser":"myNa
facturación. Obtenga información sobre me"}"
cómo etiquetar las máquinas virtuales.
Solo está disponible para las máquinas
virtuales de Resource Manager.
Información adicional Metadatos específicos del servicio. En el Máquinas virtuales

caso de las máquinas virtuales, {"ImageType":"Canonical","ServiceType":"
rellenamos lo siguiente en el campo de Standard_DS1_v2","VMName":"",
información adicional: "UsageType":"ComputeHR"}
Tipo de imagen: la imagen
específica que ejecutó. Encuentre Conjuntos de escalado de máquinas
la lista completa de cadenas virtuales
compatibles a continuación, en {"ImageType":"Canonical","ServiceType":"
Tipos de imagen. Standard_DS1_v2","VMName":"myVM1"
Tipo de servicio: el tamaño que , "UsageType":"ComputeHR"}
implementó.
VMName: el nombre de la Software Premium
máquina virtual. Solo se rellena {"ImageType":"","ServiceType":"Standard
en las máquinas virtuales del _DS1_v2","VMName":"",
conjunto de escalado. Si necesita "UsageType":"ComputeHR_SW"}
el nombre de la máquina virtual
para las máquinas virtuales del
conjunto de escalado, puede
buscarlo en la cadena del
identificador de instancia
anterior.
UsageType: especifica el tipo de
uso que representa.
ComputeHR es el uso de
Horas de proceso de la
máquina virtual
subyacente, como
Standard_D1_v2.
ComputeHR_SW es el
cambio de software
Premium si la máquina
virtual usa software
Premium, como
Microsoft R Server.
Tipo de imagen
Para algunas imágenes de la Galería de Azure, el tipo de imagen se rellena en el campo de información adicional.
Esto permite que los usuarios comprendan y hagan un seguimiento de lo que implementaron en su máquina
virtual. Los valores que se rellenan en este campo según la imagen que implementó son los siguientes:
BitRock
Canonical
FreeBSD
Open Logic
Oracle
SLES para SAP
SQL Server 14 Preview en Windows Server 2012 R2 Preview
SUSE
SUSE Premium
StorSimple Cloud Appliance
Red Hat
Red Hat for SAP Business Applications
Red Hat for SAP HANA
BYOL de cliente Windows
Windows Server BYOL
Versión preliminar de Windows Server
Tipo de servicio
El campo de tipo de servicio en el campo Información adicional corresponde al tamaño exacto de la máquina
virtual que implementó. Las máquinas virtuales de almacenamiento Premium (basadas en SSD ) y las máquinas
virtuales de almacenamiento no Premium (basadas en HDD ) tienen el mismo precio. Si implementa un tamaño
basado en SSD, como Standard_DS2_v2, verá el tamaño no SSD ("Standard_D2_v2 VM") en la columna
Subcategoría de medidor y el tamaño SSD ("Standard_DS2_v2") en el campo Información adicional.
Nombres de región
El nombre de región que se rellenó en el campo Ubicación de recurso en los detalles de uso es distinto del nombre
de la región que se usa en Azure Resource Manager. A continuación se muestra una asignación entre los valores
de región:
NOMBRE DE REGIÓN DE RESOURCE MANAGER UBICACIÓN DE LOS RECURSOS EN LOS DETALLES DE USO
australiaeast Este de Australia
australiasoutheast Sudeste de Australia
brazilsouth Sur de Brasil
CanadaCentral Centro de Canadá
CanadaEast Este de Canadá
CentralIndia Centro de la India
centralus Centro de EE. UU.
chinaeast Este de China
chinanorth Norte de China
eastasia Asia oriental
estado East US
eastus2 Este de EE. UU. 2
GermanyCentral Centro de Alemania
GermanyNortheast Nordeste de Alemania
japaneast Este de Japón
japanwest Oeste de Japón

NOMBRE DE REGIÓN DE RESOURCE MANAGER UBICACIÓN DE LOS RECURSOS EN LOS DETALLES DE USO
KoreaCentral Centro de Corea del Sur
KoreaSouth Sur de Corea del Sur
northcentralus Centro-Norte de EE. UU
northeurope Europa del Norte
southcentralus Centro-Sur de EE. UU
southeastasia Sudeste asiático
SouthIndia India meridional
UKNorth Norte de Reino Unido
uksouth Sur de Reino Unido 2
UKSouth2 Sur del Reino Unido 2
ukwest Oeste de Reino Unido
USDoDCentral Departamento de Defensa de EE. UU. Centro
USDoDEast Departamento de Defensa de EE. UU. Este
USGovArizona Gov (US): Arizona
usgoviowa USGov Iowa
USGovTexas Gov (US): Texas
usgovvirginia USGov Virginia
westcentralus Centro-oeste de EE. UU.
westeurope Europa occidental
WestIndia India occidental
westus Oeste de EE. UU.
westus2 Oeste de EE. UU. 2
Preguntas más frecuentes sobre el uso de las máquinas virtuales

¿Qué recursos se cobran cuando se implementa una máquina virtual?
Las máquinas virtuales adquieren los costos de la misma máquina virtual, de cualquier software Premium que se
ejecute en la máquina virtual, del disco administrado o la cuenta de almacenamiento asociados con la máquina
virtual y las transferencias de ancho de banda de red desde la máquina virtual.
¿Cómo se puede saber si una máquina virtual usa Ventaja híbrida de Azure en el CSV de uso?
Si realiza la implementación con Ventaja híbrida de Azure, se le cobra la tarifa de máquina virtual no de Windows
porque trae su propia licencia a la nube. En la factura, puede distinguir qué máquinas virtuales de Resource
Manager ejecutan Ventaja híbrida de Azure porque en la columna ImageType aparece "BYOL de Windows_Server"
o "BYOL de cliente_Windows".
¿Cómo se diferencian los tipos de máquina virtual básica y estándar en el CSV de uso?
Se ofrecen máquinas virtuales básica y estándar de la serie A. Si implementa una máquina virtual básica, tiene la
cadena "Basic" en la subcategoría de medidor. Si implementa una máquina virtual estándar de la serie A, el tamaño
de máquina virtual aparece como "A1 VM" porque Estándar es el valor predeterminado. Para más información
sobre las diferencias entre las máquinas virtuales básica y estándar, consulte la página de precios.
¿Qué son los tamaños ExtraSmall, Small, Medium, Large y ExtraLarge?
ExtraSmall y ExtraLarge son los nombres heredados para Estándar_A0 – Estándar_A4. En los registros de uso de
máquinas virtuales clásicas, puede ver que esta convención se usa si implementó estos tamaños.
¿Cuál es la diferencia entre la región de medidor y la ubicación de recursos?
La región de medidor está asociada con el medidor. En algunos servicios de Azure que usan un precio para todas
las regiones, el campo Región de medidor podría estar en blanco. Sin embargo, como las máquinas virtuales tienen
precios dedicados por región para las máquinas virtuales, este campo se rellena. Del mismo modo, la ubicación de
recursos de las máquinas virtuales es la ubicación donde se implementa la máquina virtual. La región de Azure de
ambos campos es la misma, si bien pueden tener una convención de cadena distinta para el nombre de la región.
¿Por qué el valor ImageType está en blanco en el campo de información adicional?
El campo ImageType se rellena solo para un subconjunto de imágenes. Si no implementó una de las imágenes
anteriores, el valor de ImageType está en blanco.
¿Por qué el valor VMName está en blanco en el campo de información adicional?
El valor VMName solo se rellena en el campo de información adicional de las máquinas virtuales de un conjunto
de escalado. El campo InstanceID contiene el nombre de máquina virtual de las máquinas virtuales que no son de
un conjunto de escalado.
¿Qué significa ComputeHR en el campo UsageType en el campo de información adicional?
ComputeHR se refiere a la hora de proceso, que representa el evento de uso para el costo de infraestructura
subyacente. Si UsageType es ComputeHR_SW, el evento de uso representa el cargo de software Premium de la
máquina virtual.
¿Cómo puedo saber si me cobran por software Premium?
Cuando explore qué imagen de máquina virtual se adapta mejor a sus necesidades, asegúrese de revisar Azure
Marketplace. La imagen tiene la tarifa del plan de software. Si la tarifa aparece como "Gratis", no hay costo
adicional por el software.
¿Cuál es la diferencia entre Microsoft.ClassicCompute y Microsoft.Compute en el servicio consumido?
Microsoft.ClassicCompute representa los recursos clásicos implementados a través de Azure Service Manager. Si
realiza la implementación a través de Resource Manager, Microsoft.Compute se rellena en el servicio consumido.
Obtenga más información sobre los modelos de implementación de Azure.
¿Por qué el campo InstanceID está en blanco en el uso de mi máquina virtual?
Si implementa a través del modelo de implementación clásica, la cadena InstanceID no está disponible.
¿Por qué las etiquetas de mis máquinas virtuales no se transmiten a los detalles de uso?
Las etiquetas solo se transmiten al CSV de uso para las máquinas virtuales de Resource Manager. Las etiquetas de
recursos clásicos no están disponibles en los detalles de uso.
¿Cómo la cantidad consumida puede ser más de 24 horas al día?
En el modelo clásico, la facturación de recursos se agrega en el nivel de servicio en la nube. Si tiene más de una
máquina virtual en un servicio en la nube que usa el mismo medidor de facturación, el uso se agrega en conjunto.
Las máquinas virtuales que se implementan a través de Resource Manager se facturan en el nivel de máquina
virtual, por lo que no se aplicará esta agregación.
¿Por qué en la página de precios no aparecen los precios de los tamaños DS/FS/GS/LS?
Las máquinas virtuales compatibles con el almacenamiento Premium se facturan con la misma tarifa que las
máquinas virtuales compatibles con el almacenamiento que no es Premium. Solo difieren los costos de
almacenamiento. Visite la página de precios de almacenamiento para más información.
Pasos siguientes
Para más información sobre los detalles de uso, consulte Comprender la factura de Microsoft Azure.
Comandos comunes de PowerShell para crear y
administrar Azure Virtual Machines
En este artículo se tratan algunos de los comandos de Azure PowerShell que puede usar para crear y administrar
máquinas virtuales de su suscripción de Azure. Para más ayuda con opciones y modificadores concretos de la línea
de comandos, puede utilizar el comando Get-Help.
Estas variables podrían serle útiles si ejecuta más de uno de los comandos de este artículo:
$location: la ubicación de la máquina virtual. Puede usar Get-AzLocation para buscar una región geográfica que
se adapte a sus necesidades.
Valor predeterminado personalizado: Nombre del grupo de recursos que contiene las máquinas virtuales.
$myVM: el nombre de la máquina virtual.
Creación de una máquina virtual: método simplificado

TAREA GET-HELP
Creación de una máquina virtual simple New-AzVM -Name $myVM
New-AzVM tiene un conjunto de parámetros simplificados

donde todo lo que se requiere es un nombre. El valor de -
Name se usará como nombre de todos los recursos necesarios
para crear una máquina virtual. Se pueden especificar más,
pero esto es todo lo necesario.
Crear una imagen personalizada a partir de una máquina New-AzVm -ResourceGroupName $myResourceGroup -Name
virtual $myVM ImageName "miImagen" -Location $location
Debe haber creado su propia imagen administrada. Puede

usar una sola imagen para crear varias máquinas virtuales
idénticas.
Creación de una configuración de máquina virtual

TAREA GET-HELP
Creación de una configuración de máquina virtual $vm = New-AzVMConfig -VMName $myVM -VMSize
"Standard_D1_v1"
La configuración de máquina virtual se utiliza para definir o

actualizar la configuración de la máquina virtual. La
configuración se inicializa con el nombre de la VM y su
tamaño.
TAREA GET-HELP
Adición de valores de configuración $vm = Set-AzVMOperatingSystem -VM $vm -Windows -

ComputerName $myVM -Credential $cred -
ProvisionVMAgent -EnableAutoUpdate
La configuración del sistema operativo que incluye

credenciales se agrega al objeto de configuración que creó
anteriormente mediante New-AzVMConfig.
Adición de una interfaz de red $vm = Add-AzVMNetworkInterface -VM $vm -Id $nic.Id
Una VM debe tener un interfaz de red para comunicarse en

una red virtual. También puede usar Get-AzNetworkInterface
para recuperar un objeto de interfaz de red existente.
Especificación de una imagen de plataforma $vm = Set-AzVMSourceImage -VM $vm -PublisherName

"nombre_publicador" -Offer "oferta_publicador" -Skus
"sku_producto" -Version "más_reciente"
La información de la imagen se agrega al objeto de

configuración que creó anteriormente mediante New-
AzVMConfig. El objeto que se devuelve con este comando
solo se utiliza cuando se establece el disco del sistema
operativo que utilizará una imagen de plataforma.
Crear una VM New-AzVM -ResourceGroupName $myResourceGroup -

Location $location -VM $vm
Todos los recursos se crean en un grupo de recursos. Antes de

ejecutar este comando, ejecute New-AzVMConfig, Set-
AzVMOperatingSystem, Set-AzVMSourceImage, Add-
AzVMNetworkInterface y Set-AzVMOSDisk.
Actualización de una máquina virtual Update-AzVM -ResourceGroupName $myResourceGroup -

VM $vm
Obtenga la configuración de VM actual mediante Get-AzVM,

cambie los valores de configuración del objeto de VM y, luego,
ejecute este comando.
Obtención de información sobre VM

TAREA GET-HELP
Enumeración de las máquinas virtuales de una suscripción Get-AzVM
Enumeración de las máquinas virtuales de un grupo de Get-AzVM -ResourceGroupName $myResourceGroup

recursos
Para obtener una lista de grupos de recursos de la suscripción,
use Get-AzResourceGroup.
Obtención información acerca de una máquina virtual Get-AzVM -ResourceGroupName $myResourceGroup -Name
$myVM

TAREA GET-HELP
Inicio de una máquina virtual Start-AzVM -ResourceGroupName $myResourceGroup -Name

$myVM
Detención de una máquina virtual Stop-AzVM -ResourceGroupName $myResourceGroup -Name

$myVM
Reinicio de una máquina virtual en ejecución Restart-AzVM -ResourceGroupName $myResourceGroup -

Name $myVM
Eliminación de una máquina virtual Remove-AzVM -ResourceGroupName $myResourceGroup -

Name $myVM
Pasos siguientes
Consulte los pasos básicos para crear una máquina virtual en Creación de una máquina virtual de Windows con
Resource Manager y PowerShell.
Cambio de tamaño de una máquina virtual Windows
En este artículo se muestra cómo mover una máquina virtual a otro tamaño de máquina virtual diferente con
Azure PowerShell.
Después de crear una máquina virtual, puede escalarla o reducirla verticalmente cambiando su tamaño. En
algunos casos, hay que desasignarla antes. Esto puede suceder si el nuevo tamaño no está disponible en el clúster
de hardware que hospeda la actualmente la máquina virtual.
Si la máquina virtual usa Premium Storage, asegúrese de elegir una versión s del tamaño para obtener
compatibilidad con este nivel de almacenamiento. Por ejemplo, elija Standard_E4s_v3 en lugar de Standard_E4_v3.
Cambio de tamaño de una máquina virtual Windows que no está en un

conjunto de disponibilidad
Establezca algunas variables. Reemplace los valores por su propia información.
$vmName = "myVM"
Muestre los tamaños de máquina virtual que están disponibles en el clúster de hardware donde se hospeda la
máquina virtual.
Get-AzVMSize -ResourceGroupName $resourceGroup -VMName $vmName
Si se muestra el tamaño deseado, ejecute los comandos siguientes para cambiar el tamaño de la máquina virtual.
Si el tamaño deseado no aparece, vaya al paso 3.
$vm = Get-AzVM -ResourceGroupName $resourceGroup -VMName $vmName

$vm.HardwareProfile.VmSize = "<newVMsize>"
Update-AzVM -VM $vm -ResourceGroupName $resourceGroup
Si el tamaño deseado no se muestra, ejecute los siguientes comandos para desasignar la máquina virtual, cambiar
su tamaño y reiniciarla. Sustituya <newVMsize> por el tamaño que quiera.
Stop-AzVM -ResourceGroupName $resourceGroup -Name $vmName -Force

$vm.HardwareProfile.VmSize = "<newVMSize>"
Start-AzVM -ResourceGroupName $resourceGroup -Name $vmName
WARNING
Al desasignar la máquina virtual, se liberan todas las direcciones IP dinámicas asignadas a ella. Esto no afecta a los discos del
SO y de datos.
Cambio de tamaño de una máquina virtual Windows que está en un

conjunto de disponibilidad
Si el nuevo tamaño de una máquina virtual de un conjunto de disponibilidad no está disponible en el clúster de
hardware que hospeda la máquina virtual, habrá que desasignar todas las máquinas virtuales del conjunto de
disponibilidad para cambiar el tamaño de la máquina virtual. También tendrá que actualizar el tamaño de otras
máquinas virtuales del conjunto de disponibilidad después de cambiar el tamaño de una máquina virtual. Para
cambiar el tamaño de una máquina virtual de un conjunto de disponibilidad, siga estos pasos.
$vmName = "myVM"
Muestre los tamaños de máquina virtual que están disponibles en el clúster de hardware donde se hospeda la
máquina virtual.
Get-AzVMSize -ResourceGroupName $resourceGroup -VMName $vmName
Si se muestra el tamaño deseado, ejecute el comando siguiente para cambiar el tamaño de la máquina virtual. Si
no aparece, vaya a la sección siguiente.

$vm.HardwareProfile.VmSize = "<newVmSize>"
Si el tamaño deseado no aparece, continúe con los pasos siguientes para desasignar todas las máquinas virtuales
del conjunto de disponibilidad, cambiar su tamaño y reiniciarlas.
Detenga todas las máquinas virtuales del conjunto de disponibilidad.
$as = Get-AzAvailabilitySet -ResourceGroupName $resourceGroup

$vmIds = $as.VirtualMachinesReferences
foreach ($vmId in $vmIDs){
$string = $vmID.Id.Split("/")
$vmName = $string[8]
Stop-AzVM -ResourceGroupName $resourceGroup -Name $vmName -Force
}
Cambie el tamaño de todas las máquinas virtuales del conjunto de disponibilidad y reinícielas.
$newSize = "<newVmSize>"
$as = Get-AzAvailabilitySet -ResourceGroupName $resourceGroup
$vmIds = $as.VirtualMachinesReferences
foreach ($vmId in $vmIDs){
$string = $vmID.Id.Split("/")
$vmName = $string[8]
$vm = Get-AzVM -ResourceGroupName $resourceGroup -Name $vmName
$vm.HardwareProfile.VmSize = $newSize
Update-AzVM -ResourceGroupName $resourceGroup -VM $vm
Start-AzVM -ResourceGroupName $resourceGroup -Name $vmName
}
Pasos siguientes
Para obtener una mayor escalabilidad, ejecute varias instancias de VM y escálelas horizontalmente. Para obtener
más información, consulte el artículo sobre escalado automático de máquinas Linux en un conjunto de escalado
de máquinas virtuales.
Intercambio del disco del sistema operativo que se
usa en una máquina virtual de Azure mediante
PowerShell
Si ya tiene una máquina virtual, pero quiere intercambiar el disco por uno de copia de seguridad u otro disco del
sistema operativo, puede usar Azure PowerShell para intercambiar los discos del sistema operativo. No es
necesario eliminar y volver a crear la máquina virtual. Incluso puede utilizar un disco administrado de otro grupo
de recursos, siempre y cuando no esté en uso.
Es necesario que la máquina virtual esté detenida o sin asignar; a continuación, el identificador de recurso del disco
administrado se puede reemplazar con el identificador de recurso de otro disco administrado.
Asegúrese de que el tipo de almacenamiento y el tamaño de la máquina virtual son compatibles con el disco que
quiere adjuntar. Por ejemplo, si el disco que quiere usar está en Premium Storage, la máquina virtual debe ser
compatible con Premium Storage (por ejemplo, debe tener un tamaño de la serie DS ). Ambos discos también
deben tener el mismo tamaño.
Obtenga una lista de discos de un grupo de recursos mediante Get-AzDisk.
Get-AzDisk -ResourceGroupName myResourceGroup | Format-Table -Property Name
Cuando tenga el nombre del disco que quiera usar, establézcalo como el disco del sistema operativo para la
máquina virtual. En este ejemplo se detiene o desasigna la máquina virtual llamada myVM y se asigna el disco
llamado newDisk como el nuevo disco del sistema operativo.
# Get the VM
$vm = Get-AzVM -ResourceGroupName myResourceGroup -Name myVM
# Make sure the VM is stopped\deallocated

Stop-AzVM -ResourceGroupName myResourceGroup -Name $vm.Name -Force
# Get the new disk that you want to swap in

$disk = Get-AzDisk -ResourceGroupName myResourceGroup -Name newDisk
# Set the VM configuration to point to the new disk

Set-AzVMOSDisk -VM $vm -ManagedDiskId $disk.Id -Name $disk.Name
# Update the VM with the new OS disk

Update-AzVM -ResourceGroupName myResourceGroup -VM $vm
# Start the VM
Start-AzVM -Name $vm.Name -ResourceGroupName myResourceGroup
Pasos siguientes
Para crear una copia de un disco, consulte Instantánea de un disco.
Etiquetado de una máquina virtual en Azure
En este artículo se describen diferentes maneras de etiquetar una máquina virtual Windows en Azure por medio
del modelo de implementación de Resource Manager. Las etiquetas son pares clave-valor definidos por el usuario
que se pueden colocar directamente en un recurso o un grupo de recursos. Actualmente, Azure admite un máximo
de 15 etiquetas por recurso y grupo de recursos. Las etiquetas se pueden colocar en un recurso en el momento de
su creación, o bien se pueden agregar a un recurso existente. Tenga en cuenta que las etiquetas solo son
compatibles con los recursos creados mediante el modelo de implementación de Resource Manager. Si desea
etiquetar una máquina virtual Linux, consulte How to tag a Linux virtual machine in Azure (Etiquetado de una
máquina virtual Linux en Azure).
Etiquetado de una máquina virtual mediante plantillas

En primer lugar, veamos el etiquetado a través de plantillas. Esta plantilla coloca etiquetas en los siguientes
recursos: proceso (máquina virtual), almacenamiento (cuenta de almacenamiento) y red (dirección IP pública, red
virtual e interfaz de red). Esta plantilla es para una máquina virtual Windows, pero se puede adaptar a máquinas
virtuales Linux.
Haga clic en el botón Implementar en Azure del vínculo de la plantilla. Esto le remitirá al Portal de Azure , donde
puede implementar esta plantilla.
Esta plantilla incluye las siguientes etiquetas: Departamento, Aplicación y Creado por. Estas etiquetas se pueden
agregar o modificar directamente en la plantilla si se desea cambiar sus nombres.
Como puede ver, las etiquetas se definen como pares de clave-valor, separados por dos puntos (:).Las etiquetas
deben definirse con este formato:
"tags": {
"Key1" : "Value1",
"Key2" : "Value2"
}
Guarde el archivo de plantilla cuando termine de modificarlo con las etiquetas que prefiera.
A continuación, en la sección Editar parámetros , puede rellenar los valores de las etiquetas.
Haga clic en Crear para implementar esta plantilla con sus valores de etiqueta.
Etiquetado a través del portal

Después de crear los recursos con etiquetas, puede ver, agregar y eliminar etiquetas en el portal.
Seleccione el icono de etiquetas para ver las etiquetas:
Para agregar una nueva etiqueta desde el portal, defina su propio par de clave-valor y guárdela.
La nueva etiqueta debería aparecer en la lista de etiquetas del recurso.

Etiquetado con PowerShell
Para crear, agregar y eliminar etiquetas a través de PowerShell, primero es preciso configurar el entorno de
PowerShell con Administrador de recursos de Azure. Una vez completada la configuración, puede colocar
etiquetas en los recursos de Compute, Network y Storage tanto al crear el recurso a través de PowerShell como
después de haberlo creado. En este artículo se centrará en la visualización y edición de etiquetas en máquinas
virtuales.
En primer lugar, navegue a una máquina virtual a través del cmdlet Get-AzVM .
PS C:\> Get-AzVM -ResourceGroupName "MyResourceGroup" -Name "MyTestVM"
Si la máquina virtual ya contiene etiquetas, verá todas ellas en el recurso:
Tags : {
"Application": "MyApp1",
"Created By": "MyName",
"Department": "MyDepartment",
"Environment": "Production"
}
Si desea agregar etiquetas a través de PowerShell, puede usar el comando Set-AzResource . Tenga en cuenta que
si actualiza las etiquetas a través de PowerShell, se actualizan todas ellas en conjunto. Por tanto, si va a agregar
una etiqueta a un recurso que ya tiene etiquetas, tendrá que incluir todas las etiquetas que desea colocar en el
recurso. A continuación se muestra un ejemplo de cómo agregar etiquetas adicionales a un recurso mediante los
cmdlets de PowerShell.
Este primer cmdlet establece todas las etiquetas colocadas en MyTestVM en la variable $tags, para lo que emplea
las propiedades Get-AzResource y Tags .
PS C:\> $tags = (Get-AzResource -ResourceGroupName MyResourceGroup -Name MyTestVM).Tags
El segundo comando muestra las etiquetas de la variable especificada.

PS C:\> $tags
Key Value
---- -----
Department MyDepartment
Application MyApp1
Created By MyName
Environment Production
El tercer comando agrega una etiqueta adicional a la variable tags . Observe el uso de += para anexar el nuevo par
de clave-valor a la lista de tags .
PS C:\> $tags += @{Location="MyLocation"}
El cuarto comando establece todas las etiquetas definidas en la variable tags en el recurso especificado. En este
caso, es MyTestVM.
PS C:\> Set-AzResource -ResourceGroupName MyResourceGroup -Name MyTestVM -ResourceType

"Microsoft.Compute/VirtualMachines" -Tag $tags
El quinto comando muestra todas las etiquetas en el recurso. Como puede ver, Location está definido como una
etiqueta, con MyLocation como valor.
PS C:\> (Get-AzResource -ResourceGroupName MyResourceGroup -Name MyTestVM).Tags
Key Value
---- -----
Department MyDepartment
Application MyApp1
Created By MyName
Environment Production
Location MyLocation
Para más información sobre el etiquetado a través de PowerShell, consulte los cmdlets de recursos de Azure.
Visualización de etiquetas en los detalles de uso

Las etiquetas colocadas en los recursos de Compute, Network y Storage en el modelo de implementación de
Resource Manager se rellenarán en los detalles de uso del portal de facturación.
Haga clic en Descargar detalles de uso para ver los detalles de uso de la suscripción.
Seleccione el extracto de facturación y los detalles de uso de la versión 2 :
En los detalles de uso puede ver todas las etiquetas en la columna de etiquetas :
Mediante el análisis de estas junto con el uso, las organizaciones podrán obtener nuevos puntos de vista en sus
datos de consumo.
Pasos siguientes
Para más información sobre el etiquetado de los recursos de Azure, consulte Información general de Azure
Resource Manager y Uso de etiquetas para organizar los recursos de Azure.
Para ver cómo las etiquetas pueden ayudarle a administrar el uso de los recursos de Azure, consulte
Comprender la factura de Microsoft Azure y Obtención de información sobre el consumo de recursos de
Microsoft Azure.
Sincronizar la hora en las máquinas virtuales de
Windows en Azure
La sincronización de la hora es importante para la seguridad y la correlación de eventos. A veces se usa en la

implementación de transacciones distribuidas. La precisión de hora entre varios sistemas de equipos se logra
mediante la sincronización. Además, la sincronización puede verse afectada por varias cosas, incluyendo las
operaciones de reinicio y el tráfico de red entre el origen de la hora y el equipo encargado de capturar la hora.
Por ello, Azure ya cuenta con la infraestructura que ejecuta Windows Server 2016. Windows Server 2016 ha
mejorado los algoritmos que se usan para corregir la hora y la condición del reloj local, y así poder sincronizarse
con la hora UTC. Asimismo, Windows Server 2016 también ha mejorado el servicio VMICTimeSync que administra
el modo de sincronizar las máquinas virtuales con el host, para obtener la hora exacta. Las mejoras incluyen una
hora inicial más precisa en el inicio o la restauración de la máquina virtual, así como la interrupción de la corrección
de la latencia para las muestras proporcionadas para la hora de Windows (W32time).
NOTE
Para obtener información general rápida del servicio Horario de Windows, eche un vistazo a este vídeo de información
general de alto nivel.
Para obtener más información, consulte el artículo Hora de Windows Server 2016 precisa.
La precisión del reloj de un equipo se mide en función de lo cerca que esté ese reloj de la hora universal
coordinada (UTC ) estándar. La UTC se define mediante una muestra internacional de relojes atómicos precisos que
solo se retrasan un segundo en 300 años. Aún así, es necesario tener hardware especializado para leer la UTC
directamente. En cambio, los servidores horarios se sincronizan con la UTC y se accede a ellos desde otros equipos
para proporcionar escalabilidad y robustez. Cada equipo tiene un servicio de sincronización de hora en ejecución
que sabe qué servidores horarios debe usar y que comprueba periódicamente si el reloj del equipo necesita ser
corregido ajustándolo si fuera necesario.
Los hosts de Azure se sincronizan con los servidores horarios internos de Microsoft que ajustan su hora a partir de
los dispositivos Stratum 1 que pertenecen a Microsoft, y que cuentan con antenas GPS. Las máquinas virtuales en
Azure pueden depender de su host para proporcionar la hora exacta (hora del host) a la máquina virtual, o la
máquina virtual puede obtener directamente la hora de un servidor horario, o de una combinación de ambas
opciones.
Las interacciones de la máquina virtual con el host también pueden afectar al reloj. Durante el mantenimiento de
conservación de la memoria las máquinas virtuales se detienen hasta 30 segundos. Por ejemplo, antes de que
comience el proceso de mantenimiento que dura 28 segundos, el reloj de la máquina virtual muestra las 10:00:00
A.M. Cuando se reanuda la máquina virtual, el reloj de la misma todavía muestra las 10:00:00 A.M., por lo que
tendría 28 segundos de retraso. Para corregir esto, el servicio VMICTimeSync supervisa lo que sucede en el host y
solicita que se realicen cambios en las máquinas virtuales para compensar este retraso.
El servicio VMICTimeSync funciona en modo de ejemplo o sincronización y solamente influirá en el reloj desde ese
momento en adelante. En el modo de ejemplo, que requiere que W32time esté en ejecución, el servicio
VMICTimeSync sondea el host cada 5 segundos y proporciona ejemplos de tiempo a W32time. Aproximadamente
cada 30 segundos, el servicio W32time toma la última muestra de tiempo y la utiliza para influir en el reloj del
invitado. El modo de sincronización se activa si un invitado se ha reanudado o si el reloj de un invitado alcanza un
retraso de más de cinco segundos respecto del reloj del host. Cuando el servicio W32time se ejecuta
correctamente, este último caso no debe producirse nunca.
Por supuesto, si la sincronización de la hora no funciona, el reloj de la máquina virtual solo acumularía errores.
Cuando solo hay una máquina virtual, este efecto puede no ser significativo a menos que la carga de trabajo
requiera un cronometraje altamente preciso. Aún así, en la mayoría de los casos hay varias máquinas virtuales
conectadas entre sí que usan la hora para realizar el seguimiento de las transacciones, por lo que esta hora debe
ser consistente en toda la implementación. Cuando la hora de las máquinas virtuales es diferente, puede ver los
siguientes efectos:
Se produce un error en la autenticación. Los protocolos de seguridad como Kerberos o la tecnología
dependiente de los certificados confían en que la hora sea consistente en todos los sistemas.
Es muy difícil averiguar qué ha ocurrido en un sistema si los registros (u otros datos) tienen horas diferentes.
Parecería que el mismo evento ocurrió en diferentes momentos, lo que dificulta la correlación.
Si el reloj está atrasado, es posible que la facturación no se calcule correctamente.
Los mejores resultados para las implementaciones de Windows se logran utilizando Windows Server 2016 como
sistema operativo invitado, lo que garantiza que pueda usar las últimas mejoras en la sincronización horaria.
Opciones de configuración
Existen tres opciones para configurar la sincronización horaria de las máquinas virtuales de Windows alojadas en
Azure:
Hora del host y time.windows.com. Esta es la configuración predeterminada que se usa en las imágenes de
Azure Marketplace.
Solo para el host.
Use otro servidor horario externo con o sin usar la hora del host.
Usar el valor predeterminado
De forma predeterminada, las imágenes de la máquina virtual del sistema operativo Windows están configuradas
para que w32time se sincronice desde dos orígenes:
El proveedor NtpClient, que obtiene información de time.windows.com.
El servicio VMICTimeSync, que se usa para comunicar la hora del host a las máquinas virtuales y hacer
correcciones después de pausar la máquina virtual para el proceso de mantenimiento. Los hosts de Azure usan
dispositivos Stratum 1 de Microsoft para mantener la exactitud de la hora.
Es preferible que el proveedor horario esté establecido en el siguiente orden de prioridad en w32time: nivel de
capa, retraso de raíz, dispersión de raíz, desplazamiento de la hora. En la mayoría de los casos, es preferible que el
host de w32time sea time.windows.com, porque time.windows.com informa a una capa más baja.
En cuanto a las máquinas unidas al dominio, el propio dominio establece una jerarquía de sincronización de hora,
pero la raíz del bosque aún necesita saber la hora de alguna parte y las siguientes consideraciones seguirían
contando con el valor "true".
Solo para el host
Debido a que time.windows.com es un servidor NTP público, la hora de sincronización del mismo requiere enviar
tráfico a través de Internet, por lo que los distintos retrasos en los paquetes que se envían pueden afectar
negativamente la calidad de la sincronización de la hora. Si elimina time.windows.com y cambia a la sincronización
solo para el host, puede mejorar los resultados de sincronización de hora.
Tenga en cuenta que solo merece la pena cambiar a la sincronización de hora solo para el host si tiene problemas al
sincronizar la hora con la configuración predeterminada. Pruebe la sincronización solo para el host y compruebe si
así mejora la sincronización de hora en la máquina virtual.
Servidor de hora externo
Si tiene requisitos de sincronización horaria específica, también hay una opción que le permitirá usar servidores
horarios externos. Los servidores horarios externos pueden proporcionar una hora específica, que puede ser útil
para escenarios de prueba; gracias a ello, asegurará la uniformidad de la hora de las máquinas hospedadas en
centros de datos que no sean de Microsoft, o podrá controlar los segundos intercalares de una manera especial.
Puede combinar servidores externos con el servicio VMICTimeSync y VMICTimeProvider para proporcionar
resultados similares a los de la configuración predeterminada.
Compruebe la configuración
Compruebe si el proveedor horario NtpClient está configurado para usar servidores NTP explícitos (NTP ) o la
sincronización de hora del dominio (NT5DS ).
w32tm /dumpreg /subkey:Parameters | findstr /i "type"
Si la máquina virtual está usando NTP, verá el siguiente resultado:
Value Name Value Type Value Data

Type REG_SZ NTP
Para ver a qué servidor horario está usando el proveedor horario NtpClient, escriba lo siguiente en un símbolo del
sistema con privilegios elevados:
w32tm /dumpreg /subkey:Parameters | findstr /i "ntpserver"
Si la máquina virtual está usando el valor predeterminado, el resultado tendrá el siguiente aspecto:
NtpServer REG_SZ time.windows.com,0x8
Para ver qué proveedor horario está utilizando actualmente.
w32tm /query /source
Estos son los resultados que podría ver y lo que significan:

time.windows.com: en la configuración predeterminada, w32time obtiene la hora de time.windows.com. La
calidad de la sincronización de la hora depende de la conectividad de Internet, y se ve afectada por los retrasos
de los paquetes. Este es el resultado habitual de la configuración predeterminada.
Proveedor de sincronización de hora de IC de la máquina virtual: la máquina virtual sincroniza la hora
desde el host. Por lo general, este es el resultado que aparece si opta por sincronizar la hora solo con el host o si
el servidor NtpServer no está disponible en ese momento.
Su servidor de dominio: la máquina actual está en un dominio y el dominio define la jerarquía de sincronización
de hora.
Algún otro servidor: w32time se configuró explícitamente para obtener la hora de otro servidor. La calidad de la
sincronización de la hora depende de la calidad del servidor horario.
Reloj local CMOS: el reloj no está sincronizado. Puede obtener este resultado si w32time no ha tenido tiempo
suficiente para iniciarse tras un reinicio, o cuando no están disponibles todos los orígenes de la hora
configurados.
Habilitar la sincronización de hora desde un único host
Azure trabaja constantemente para mejorar la sincronización de la hora en los hosts y puede garantizar que toda la
infraestructura de sincronización de hora se encuentra en centros de datos propiedad de Microsoft. Si tiene
problemas con la sincronización horaria de la configuración predeterminada porque usa time.windows.com como
fuente principal para obtener la hora, puede usar los siguientes comandos para habilitar la sincronización horaria
des de un único host.
Marque el proveedor de VMIC como habilitado.
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\VMICTimeProvider /v Enabled

/t REG_DWORD /d 1 /f
Marque el proveedor NTPClient como deshabilitado.
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpClient /v Enabled /t

REG_DWORD /d 0 /f
Reinicie el servicio w32time.
net stop w32time && net start w32time
Máquinas virtuales de Windows Server 2012 y R2

Windows Server 2012 y Windows Server 2012 R2 tienen diferentes configuraciones predeterminadas para la
sincronización horaria. El servicio w32time se configura por defecto para obtener una baja sobrecarga del servicio
en lugar de la hora precisa.
Si desea mover sus implementaciones de Windows Server 2012 y 2012 R2 para que usen los valores
predeterminados más recientes y que así antepongan la precisión horaria, puede aplicar la siguiente configuración.
Actualice el sondeo de w32time y actualice los intervalos para que coincidan con la configuración de Windows
Server 2016.
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v MinPollInterval /t REG_DWORD /d

6 /f
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v MaxPollInterval /t REG_DWORD /d
10 /f
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UpdateInterval /t REG_DWORD /d
100 /f
w32tm /config /update
Para que w32time pueda usar los nuevos intervalos de sondeo, NtpServers también debe usarlos. Si los servidores
están anotados con una máscara de indicador de bits de 0x1, esto anularía este mecanismo y w32time usaría
SpecialPollInterval en su lugar. Asegúrese de que los servidores NTP especificados estén utilizando una marca 0x8
o ninguna marca:
Compruebe las marcas que se utilizan para los servidores NTP.
w32tm /dumpreg /subkey:Parameters | findstr /i "ntpserver"
Pasos siguientes
A continuación le ofrecemos varios vínculos para obtener más detalles sobre la sincronización horaria:
Windows Time Service Tools and Settings (Herramientas y configuración del servicio de hora de Windows)
Windows Server 2016 Improvements (Mejoras de Windows Server 2016)
Accurate Time for Windows Server 2016 (Hora exacta para Windows Server 2016)
Support boundary to configure the Windows Time service for high-accuracy environments (Límite del soporte
técnico para configurar el servicio de hora de Windows en entornos de alta precisión)
Ejecución de scripts en una máquina virtual Windows
Para automatizar las tareas o solucionar los problemas, es posible que deba ejecutar comandos en una máquina
virtual. El artículo siguiente ofrece una breve introducción a las características disponibles para ejecutar scripts y
comandos dentro de las máquinas virtuales.
Custom Script Extension

La extensión de scripts personalizados se usa principalmente para la instalación de software y la configuración
después de la implementación.
Descargue y ejecute scripts en máquinas virtuales de Azure.
Se puede ejecutar mediante las plantillas de Azure Resource Manager, la CLI de Azure, la API de REST,
PowerShell o Azure Portal.
Los archivos de script se pueden descargar de Azure Storage o GitHub, o bien se pueden proporcionar desde el
equipo si la ejecución se realiza desde Azure Portal.
Ejecute un script de PowerShell en máquinas Windows y un script de Bash en máquinas Linux.
Es útil para la configuración posterior a la implementación, la instalación de software y otras tareas de
configuración o administración.
Comando Ejecutar
La característica Comando Ejecutar habilita la administración de máquinas virtuales y aplicaciones y la solución de
problemas mediante scripts, y está disponible incluso cuando no se puede acceder a la máquina, por ejemplo, si el
firewall invitado no tiene abierto el puerto RDP o SSH.
Ejecute scripts en máquinas virtuales de Azure.
Se puede ejecutar mediante Azure Portal, la API de REST, la CLI de Azure o PowerShell.
Ejecute un script, vea la salida rápidamente y repita según sea necesario en Azure Portal.
El script se puede ejecutar directamente o puede ejecutar uno de los scripts integrados.
Ejecute un script de PowerShell en máquinas Windows y un script de Bash en máquinas Linux.
Es útil para la administración de máquinas virtuales y aplicaciones y para ejecutar scripts en máquinas virtuales
a las que no se puede acceder.
Hybrid Runbook Worker

Hybrid Runbook Worker brinda administración general de máquinas, aplicaciones y entornos con scripts
personalizados del usuario almacenados en una cuenta de Automation.
Ejecute scripts en máquinas de Azure y en máquinas que no son de Azure.
Se puede ejecutar mediante Azure Portal, la CLI de Azure, la API de REST, PowerShell, WebHook.
Los scripts se almacenan y administran en una cuenta de Automation.
Ejecute PowerShell, Flujo de trabajo de PowerShell, Python o runbooks gráficos.
No hay límite de tiempo en el tiempo de ejecución de los scripts.
Varios scripts se pueden ejecutar de manera simultánea.
Se devuelve y almacena toda la salida de un script.
Historial de trabajos disponible durante 90 días.
Los scripts se pueden ejecutar como sistema local o con credenciales suministradas por el usuario.
Requiere instalación manual.
Consola de serie
La consola serie brinda acceso directo a una máquina virtual, igual que si tuviera un teclado conectado a la
máquina virtual.
Ejecute comandos en máquinas virtuales de Azure.
Se puede ejecutar mediante una consola basada en texto en la máquina en Azure Portal.
Inicie sesión en la máquina con una cuenta de usuario local.
Es útil cuando se requiere acceso a la máquina virtual independientemente del estado del sistema operativo o
de la red de la máquina.
Pasos siguientes
Más información sobre las distintas características disponibles para ejecutar scripts y comandos dentro de las
Extensión Custom Script
Comando Ejecutar
Trabajo híbrido de runbook
Consola serie
Extensión de la secuencia de comandos personalizada para Windows
La extensión de script personalizado descarga y ejecuta scripts en máquinas virtuales de Azure. Esta extensión es útil para la configuración posterior a la
implementación, la instalación de software o cualquier otra tarea de configuración o administración. Los scripts se pueden descargar desde Azure Storage o GitHub, o
se pueden proporcionar a Azure Portal en el tiempo de ejecución de la extensión. La extensión de script personalizado se integra con las plantillas de Azure Resource
Manager y se puede ejecutar mediante la CLI de Azure, PowerShell, Azure Portal o la API de REST de máquina virtual de Azure.
En este documento se detalla cómo usar la extensión de script personalizado mediante el módulo de Azure PowerShell y plantillas de Azure Resource Manager, y se
detallan también los pasos para solucionar problemas en los sistemas Windows.
Requisitos previos
NOTE
No use la extensión de script personalizado para ejecutar Update-AzVM con la misma VM como su parámetro, ya tendrá que hacerlo ella misma.
Sistema operativo
La extensión de script personalizado para Windows se ejecuta en los sistemas operativos que la admiten. Para obtener más información, vea Sistemas operativos
compatibles con extensión de Azure.
Ubicación del script
Puede configurar la extensión para usar las credenciales de Azure Blob Storage a fin de acceder a Azure Blob Storage. La ubicación del script puede ser cualquier
lugar, siempre y cuando la máquina virtual pueda enrutarse a ese punto final, como GitHub o un servidor de archivos interno.
Conectividad de Internet
Si necesita descargar un script externamente, por ejemplo desde GitHub o Azure Storage, deben abrirse puertos adicionales de firewall y grupo de seguridad de red.
Por ejemplo, si el script se encuentra en Azure Storage, puede permitir el acceso mediante las etiquetas del servicio NSG de Azure para Storage.
Si el script se encuentra en un servidor local, puede que aún necesite abrir puertos adicionales de firewall y grupo de seguridad de red.
Trucos y sugerencias
La mayor tasa de errores de esta extensión se debe a errores de sintaxis en el script. Compruebe que el script se ejecuta sin errores y además establezca registros
adicionales en él para facilitar la búsqueda de dónde se ha producido el error.
Escriba scripts que sean idempotentes. Esto garantiza que si se ejecutan de nuevo accidentalmente, no van a provocar cambios en el sistema.
Asegúrese de que los scripts no requieran intervención del usuario cuando se ejecutan.
Los scripts tienen permitido un plazo de 90 minutos para ejecutarse; todo lo que dure más provocará un error de aprovisionamiento de la extensión.
No incluya reinicios en el script, ya que esta acción provocará errores con otras extensiones que se instalen. Después del reinicio, la extensión no continuará
después del reinicio.
Si tiene un script que provoca un reinicio, instala aplicaciones y ejecuta scripts, puede programar el reinicio con una tarea programada de Windows o usar
herramientas como las extensiones DSC, Chef o Puppet.
La extensión solo ejecutará un script una vez. Si quiere ejecutar un script en cada inicio, debe usar la extensión para crear una tarea programada de Windows.
Si quiere programar cuándo se ejecutará un script, debe usar la extensión para crear una tarea programada de Windows.
Cuando el script se esté ejecutando, solo verá un estado de extensión "en transición" desde Azure Portal o la CLI. Si quiere recibir actualizaciones de estado más
frecuentes de un script en ejecución, debe crear su propia solución.
La extensión de script personalizada no admite de forma nativa servidores proxy, pero puede usar una herramienta de transferencia de archivos que admita
servidores proxy en el script, como Curl.
Tenga en cuenta las ubicaciones de directorio no predeterminadas en las que se puedan basar los scripts o comandos y aplique lógica para controlar esta situación.
La extensión de script personalizado se ejecutará con la cuenta LocalSystem
Esquema de extensión
La configuración de la extensión de script personalizado especifica aspectos como la ubicación del script y el comando que se ejecutará. Esta configuración se puede
almacenar en archivos de configuración, o se puede especificar en la línea de comandos o en una plantilla de Azure Resource Manager.
Los datos confidenciales se pueden almacenar en una configuración protegida, que se cifra y se descifra solo dentro de la máquina virtual. La configuración protegida
es útil cuando el comando de ejecución incluye secretos tales como una contraseña.
Estos elementos se deben tratar como datos confidenciales y se deben especificar en la configuración protegida de las extensiones. Los datos de configuración
protegida de la extensión de VM de Azure están cifrados y solo se descifran en la máquina virtual de destino.
{
"apiVersion": "2018-06-01",
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "virtualMachineName/config-app",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'),copyindex())]",
"[variables('musicstoresqlName')]"
],
"tags": {
"displayName": "config-app"
},
"properties": {
"publisher": "Microsoft.Compute",
"type": "CustomScriptExtension",
"typeHandlerVersion": "1.9",
"autoUpgradeMinorVersion": true,
"settings": {
"fileUris": [
"script location"
],
"timestamp":123456789
},
"protectedSettings": {
"commandToExecute": "myExecutionCommand",
"storageAccountName": "myStorageAccountName",
"storageAccountKey": "myStorageAccountKey"
}
}
}
NOTE
Solo se puede instalar una versión de una extensión en una máquina virtual en un momento dado. Si se especifica el script personalizado dos veces en la misma plantilla de Resource
Manager para la misma máquina virtual, se produce un error.
NOTE
Este esquema se puede usar dentro del recurso VirtualMachine o como un recurso independiente. El nombre del recurso debe tener el formato "virtualMachineName/extensionName"
si se usa esta extensión como recurso independiente en la plantilla de ARM.
Valores de propiedad
NOMBRE VALOR / EJEMPLO TIPO DE DATOS
apiVersion 2015-06-15 date
publisher Microsoft.Compute string
type CustomScriptExtension string
typeHandlerVersion 1.9 int
fileUris (p. ej.) https://raw.githubusercontent.com/Microsoft/dotnet-core- array

sample-templates/master/dotnet-core-music-
windows/scripts/configure-music-app.ps1
timestamp (p. ej.) 123456789 Entero de 32 bits
commandToExecute (p. ej.) powershell -ExecutionPolicy Unrestricted -File configure- string

music-app.ps1
storageAccountName (p. ej.) examplestorageacct string
storageAccountKey (p. ej.) TmJK/1N3AbAZ3q/+hOXoi/l73zOqsaxXDhqa9Y83/v5UpX string

Qp2DQIBuv2Tifp60cE/OaHsJZmQZ7teQfczQj8hg==
NOTE
Los nombres de propiedad distinguen entre mayúsculas y minúsculas. Para evitar problemas de implementación, use los nombres como se muestran aquí.
Detalles del valor de propiedad

commandToExecute (necesario, cadena): script de punto de entrada que se va a ejecutar. Use este campo si el comando contiene secretos, como contraseñas, o si los
fileUris son confidenciales.
fileUris (opcional, matriz de cadenas): direcciones URL de los archivos que se van a descargar.
timestamp (opcional, entero de 32 bits) use este campo solo para desencadenar una nueva ejecución del script; para ello, cambie el valor de este campo. Se acepta
cualquier valor entero; solo debe ser distinto del valor anterior.
storageAccountName (opcional, cadena): nombre de la cuenta de almacenamiento. Si especifica credenciales de almacenamiento, todos los valores de fileUris
deben ser direcciones URL de blobs de Azure.
storageAccountKey (opcional, cadena): clave de acceso de la cuenta de almacenamiento.
Los valores siguientes se pueden establecer en la configuración pública o protegida. La extensión rechazará una configuración si los valores siguientes están
establecidos en la configuración tanto pública como protegida.
commandToExecute
El empleo de la configuración pública puede resultar útil para la depuración, pero se recomienda usar la configuración protegida.
La configuración pública se envía en texto no cifrado a la máquina virtual donde se ejecutará el script. La configuración protegida se cifra con una clave que solo
conocen Azure y la máquina virtual. La configuración se guarda en la máquina virtual tal cual se ha enviado, es decir, si la configuración estaba cifrada, se guarda
cifrada en la máquina virtual. El certificado usado para descifrar los valores cifrados se almacena en la máquina virtual y se usa para descifrar la configuración (si es
necesario) en tiempo de ejecución.
Implementación de plantilla
Las extensiones de VM de Azure pueden implementarse con plantillas de Azure Resource Manager. El esquema JSON detallado en la sección anterior se puede usar
en una plantilla de Azure Resource Manager para ejecutar la extensión de script personalizado durante la implementación. En los ejemplos siguientes se muestra
cómo usar la extensión de script personalizado:
Tutorial: Implementación de extensiones de máquina virtual con plantillas de Azure Resource Manager
Deploy Two Tier Application on Windows and Azure SQL DB (Implementación de aplicaciones de dos niveles en Windows y Azure SQL DB)
Implementación de PowerShell
El comando Set-AzVMCustomScriptExtension se puede usar para agregar la extensión de script personalizado a una máquina virtual existente. Para más información,
consulte Set-AzVMCustomScriptExtension.
Set-AzVMCustomScriptExtension -ResourceGroupName <resourceGroupName> `

-VMName <vmName> `
-Location myLocation `
-FileUri <fileUrl> `
-Run 'myScript.ps1' `
-Name DemoScriptExtension
Ejemplos adicionales
Empleo de varios scripts
En este ejemplo hay tres scripts que se usan para compilar el servidor. commandToExecute llama al primer script y luego se dispone de opciones sobre cómo llamar
a los demás. Por ejemplo, puede tener un script maestro que controla la ejecución con el control de errores, el registro y la administración de estado adecuados. Los
scripts se descargan en el equipo local para su ejecución. Por ejemplo, en 1_Add_Tools.ps1 se llamaría a 2_Add_Features.ps1 al agregar .\2_Add_Features.ps1 al script
y se repetiría este proceso para los demás scripts definidos en $settings .
$fileUri = @("https://xxxxxxx.blob.core.windows.net/buildServer1/1_Add_Tools.ps1",
"https://xxxxxxx.blob.core.windows.net/buildServer1/2_Add_Features.ps1",
"https://xxxxxxx.blob.core.windows.net/buildServer1/3_CompleteInstall.ps1")
$settings = @{"fileUris" = $fileUri};
$storageAcctName = "xxxxxxx"
$storageKey = "1234ABCD"
$protectedSettings = @{"storageAccountName" = $storageAcctName; "storageAccountKey" = $storageKey; "commandToExecute" = "powershell -ExecutionPolicy Unrestricted
-File 1_Add_Tools.ps1"};
#run command
Set-AzVMExtension -ResourceGroupName <resourceGroupName> `
-Location <locationName> `
-VMName <vmName> `
-Name "buildserver1" `
-TypeHandlerVersion "1.9" `
-Settings $settings `
-ProtectedSettings $protectedSettings `
Ejecutar scripts desde un recurso compartido local

En este ejemplo es posible que quiera usar un servidor local de SMB para la ubicación del script. Así, no es necesario proporcionar ningún otro valor de
configuración, excepto commandToExecute.
$protectedSettings = @{"commandToExecute" = "powershell -ExecutionPolicy Unrestricted -File \\filesvr\build\serverUpdate1.ps1"};
Set-AzVMExtension -ResourceGroupName <resourceGroupName> `

-Location <locationName> `
-VMName <vmName> `
-Name "serverUpdate"
-TypeHandlerVersion "1.9" `
-ProtectedSettings $protectedSettings
Cómo ejecutar un script personalizado más de una vez con la CLI

Si quiere ejecutar la extensión de script personalizado más de una vez, solo puede hacer esta acción si se cumplen las condiciones siguientes:
El parámetro Name de la extensión coincide con la implementación anterior de la extensión.
Actualice la configuración, ya que de lo contrario el comando no vuelve a ejecutarse. Puede agregar una propiedad dinámica en el comando, como una marca de
tiempo.
También puede establecer la propiedad ForceUpdateTag en true.
Empleo de Invoke-WebRequest
Si usa Invoke-WebRequest en el script, debe especificar el parámetro -UseBasicParsing , ya que de lo contrario aparece el siguiente error al comprobar el estado
detallado:
The response content cannot be parsed because the Internet Explorer engine is not available, or Internet Explorer's first-launch configuration is not complete.
Specify the UseBasicParsing parameter and try again.
Máquinas virtuales clásicas

Para implementar la extensión de script personalizado en máquinas virtuales clásicas, puede usar Azure Portal o los cmdlets clásicos de Azure PowerShell.
Portal de Azure
Vaya al recurso de máquina virtual clásica. Seleccione Extensiones en Configuración.
Haga clic en + Agregar y, en la lista de recursos, seleccione Extensión de script personalizado.
En la página Instalar extensión, seleccione el archivo de PowerShell local, rellene los argumentos y haga clic en Aceptar.
PowerShell
Use el cmdlet Set-AzureVMCustomScriptExtension para agregar la extensión de script personalizado a una máquina virtual existente.
# define your file URI

$fileUri = 'https://xxxxxxx.blob.core.windows.net/scripts/Create-File.ps1'
# create vm object
$vm = Get-AzureVM -Name <vmName> -ServiceName <cloudServiceName>
# set extension
Set-AzureVMCustomScriptExtension -VM $vm -FileUri $fileUri -Run 'Create-File.ps1'
# update vm
$vm | Update-AzureVM
Solución de problemas y asistencia

Los datos sobre el estado de las implementaciones de extensiones pueden recuperarse desde Azure Portal y mediante el módulo Azure PowerShell. Para ver el estado
de implementación de las extensiones de una máquina virtual determinada, ejecute el comando siguiente:
Get-AzVMExtension -ResourceGroupName <resourceGroupName> -VMName <vmName> -Name myExtensionName
La salida de la extensión se registra en archivos que se encuentran en la siguiente carpeta de la máquina virtual de destino.
C:\WindowsAzure\Logs\Plugins\Microsoft.Compute.CustomScriptExtension
Los archivos especificados se descargan en la siguiente carpeta de la máquina virtual de destino.
C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.*\Downloads\<n>
donde <n> es un entero decimal que puede variar entre las ejecuciones de la extensión. El valor 1.* coincide con el valor typeHandlerVersion actual y real de la
extensión. Por ejemplo, el directorio real podría ser C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.8\Downloads\2 .
Cuando se ejecute el comando commandToExecute , la extensión establece este directorio (por ejemplo, ...\Downloads\2 ) como directorio de trabajo actual. Este
proceso permite el uso de rutas de acceso relativas para buscar los archivos descargados mediante la propiedad fileURIs . En la tabla siguiente se muestran algunos
ejemplos.
Dado que la ruta de acceso absoluta de descarga puede variar con el paso del tiempo, es mejor optar por rutas de acceso relativas de archivo o script en la cadena
commandToExecute , siempre que sea posible. Por ejemplo:
"commandToExecute": "powershell.exe . . . -File \"./scripts/myscript.ps1\""
Se conserva la información de la ruta de acceso tras el primer segmento de URI de los archivos descargados a través de la lista de propiedades fileUris . Como se
muestra en la tabla siguiente, los archivos descargados se asignan en los subdirectorios de descarga para reflejar la estructura de los valores fileUris .
Ejemplos de archivos descargados
URI EN FILEURIS UBICACIÓN DESCARGADA RELATIVA UBICACIÓN DESCARGADA ABSOLUTA1
https://someAcct.blob.core.windows.net/aContainer/scripts/myscript.ps1
./scripts/myscript.ps1 C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.8\Downloa
https://someAcct.blob.core.windows.net/aContainer/topLevel.ps1
./topLevel.ps1 C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.8\Downloa
1 Las rutas de acceso absolutas del directorio cambian a lo largo del ciclo de vida de la máquina virtual, pero no durante una ejecución única de la extensión de script
personalizado.
Soporte técnico
Si necesita más ayuda con cualquier aspecto de este artículo, puede ponerse en contacto con los expertos de Azure en los foros de MSDN Azure o Stack Overflow.
También puede registrar un incidente de soporte técnico de Azure. Vaya al sitio de soporte técnico de Azure y seleccione Obtener soporte. Para obtener información
sobre el uso del soporte técnico, lea las Preguntas más frecuentes de soporte técnico de Microsoft Azure.
Ejecución de scripts de PowerShell en la máquina
virtual Windows mediante Ejecutar comando
La función Ejecutar comando usa el agente de máquina virtual (VM ) para ejecutar los scripts de PowerShell de
una VM Windows de Azure. Puede usar estos scripts para la administración general de máquinas o aplicaciones.
Pueden ayudarle a diagnosticar y corregir rápidamente el acceso a la máquina virtual y los problemas de red, así
como a revertir la máquina virtual a un buen estado.
Ventajas
Puede acceder a las máquinas virtuales de varias maneras. Ejecutar comando puede ejecutar scripts en sus
máquinas virtuales de forma remota con el agente de VM. Ejecutar comando se usa mediante Azure Portal, la API
REST o PowerShell para VM con Windows.
Esta funcionalidad es útil en todos los escenarios en los que quiera ejecutar un script en una máquina virtual. Es
uno de los únicos métodos para solucionar problemas y corregir una máquina virtual que no tiene abierto el
puerto RDP o SSH debido a una configuración incorrecta de red o de usuario administrativo.
Restricciones
Las siguientes consideraciones se aplican al usar el Ejecutar comando:
La salida se limita a los últimos 4096 bytes.
El tiempo mínimo para ejecutar un script es de aproximadamente 20 segundos.
Los script se ejecutan como sistema en Windows.
Se puede ejecutar un script a la vez.
No se admiten los scripts que solicitan información (modo interactivo).
No se puede cancelar un script en ejecución.
El tiempo máximo que se puede ejecutar un script es de 90 minutos. Después, se agotará el tiempo de espera.
La conectividad saliente de la máquina virtual es necesaria para devolver los resultados del script.
NOTE
Para poder funcionar correctamente, Ejecutar comando requiere conectividad (puerto 443) a las direcciones IP públicas de
Azure. Si la extensión no tiene acceso a estos puntos de conexión, los scripts pueden ejecutarse correctamente, pero no
devuelven los resultados. Si va a bloquear el tráfico de la máquina virtual, puede usar las etiquetas de servicio para permitir
el tráfico a las direcciones IP públicas de Azure mediante la etiqueta AzureCloud .
Comandos disponibles
Esta tabla muestra la lista de comandos disponibles para máquinas virtuales Windows. Puede usar el comando
RunPowerShellScript para ejecutar cualquier script personalizado. Al usar la CLI de Azure o PowerShell para
ejecutar un comando, el valor que se proporciona para el parámetro --command-id o -CommandId debe ser uno de
los siguientes valores. Cuando se especifica un valor que no es un comando disponible, se recibe este error:
The entity was not found in this Azure location

NOMBRE DESCRIPCIÓN
RunPowerShellScript Ejecuta un script de PowerShell.
EnableRemotePS Configura la máquina para habilitar PowerShell remoto.
EnableAdminAccount Comprueba si la cuenta de administrador local está

deshabilitada, y si lo está, la habilita.
IPConfig Muestra información detallada de la dirección IP, la máscara

de subred y la puerta de enlace predeterminada de cada
adaptador enlazado a TCP/IP.
RDPSettings Comprueba la configuración del registro y de la directiva de

dominio. Recomienda acciones de directiva si la máquina
forma parte de un dominio o modifica la configuración a los
valores predeterminados.
ResetRDPCert Quita el certificado SSL asociado al agente de escucha RDP y

restaura la seguridad de este a los valores predeterminados.
Use este script si ve algún problema con el certificado.
SetRDPPort Establece el número de puerto especificado por el usuario o

predeterminado para las conexiones del Escritorio remoto.
Habilita las reglas de firewall para el acceso entrante al puerto.
CLI de Azure
El siguiente ejemplo utiliza el comando az vm run-command para ejecutar un script de shell en una máquina
virtual Windows de Azure.
# script.ps1
# param(
# [string]$arg1,
# [string]$arg2
# )
# Write-Host This is a sample script with parameters $arg1 and $arg2
az vm run-command invoke --command-id RunPowerShellScript --name win-vm -g my-resource-group \

--scripts @script.ps1 --parameters "arg1=somefoo" "arg2=somebar"
Portal de Azure
Navegue hasta una máquina virtual en Azure Portal y seleccione Ejecutar comando en OPERACIONES. Se
mostrará una lista de los comandos disponibles para ejecutarse en la máquina virtual.
Elija un comando para ejecutar. Algunos de los comandos pueden tener parámetros de entrada obligatorios u
opcionales. Para estos comandos, los parámetros se presentan como campos de texto para que pueda
proporcionar los valores de entrada. Para cada comando, puede ver el script que se está ejecutando si expande
Ver script. RunPowerShellScript es diferente de los otros comandos, ya que permite proporcionar sus propios
scripts personalizados.
NOTE
Los comandos integrados no son editables.
Después de elegir el comando, seleccione Ejecutar para ejecutar el script. Una vez finalizada la ejecución del
script, se devuelven el resultado y los errores en la ventana de salida. La siguiente captura de pantalla muestra un
ejemplo de salida tras ejecutar el comando RDPSettings.
PowerShell
En el siguiente ejemplo se utiliza el cmdlet Invoke-AzVMRunCommand para ejecutar un script de PowerShell en
una VM de Azure. El cmdlet espera que el script al que se hace referencia en el parámetro -ScriptPath tenga una
ubicación local allí donde se está ejecutando el cmdlet.
Invoke-AzVMRunCommand -ResourceGroupName '<myResourceGroup>' -Name '<myVMName>' -CommandId

'RunPowerShellScript' -ScriptPath '<pathToScript>' -Parameter @{"arg1" = "var1";"arg2" = "var2"}
Limitación del acceso al comando Ejecutar

Para enumerar los comandos ejecutados o mostrar los detalles de un comando, se requiere el permiso
Microsoft.Compute/locations/runCommands/read en el nivel de suscripción. El rol de lector integrado tiene este
permiso, al igual que los roles superiores.
Para ejecutar un comando se requiere el permiso Microsoft.Compute/virtualMachines/runCommand/action en el nivel
de suscripción. El rol colaborador de la máquina virtual tiene este permiso, al igual que los roles superiores.
Puede usar uno de los roles integrados o crear uno personalizado para usar Ejecutar comando.
Pasos siguientes
Para obtener información sobre otras maneras de ejecutar comandos y scripts de forma remota en la máquina
virtual, consulte Ejecución de scripts en una máquina virtual Windows.
Uso de la unidad de disco D: como unidad de datos
en una máquina virtual Windows
Si su aplicación necesita usar la unidad D para almacenar datos, siga estas instrucciones para usar una unidad
distinta para el disco temporal. Nunca use el disco temporal para almacenar los datos que desee conservar.
Si se cambia el tamaño o se selecciona Detener (desasignar) una máquina virtual, se puede desencadenar la
colocación de la máquina virtual en un hipervisor nuevo. Un evento de mantenimiento planificado o no
planificado también puede desencadenar esta colocación. En este escenario, el disco temporal se reasignará a la
primera letra de unidad disponible. Si tiene una aplicación que necesita específicamente la unidad D:, debe seguir
estos pasos para mover temporalmente el archivo pagefile.sys, adjuntar un nuevo disco de datos, asignarle la letra
D y devolver el archivo pagefile.sys a la unidad temporal. Cuando lo haya hecho, Azure no devolverá D: si la
máquina virtual se desplaza a un hipervisor diferente.
Para obtener más información sobre cómo usa Azure el disco temporal, consulte Understanding the temporary
drive on Microsoft Azure Virtual Machines
Conectar el disco de datos

En primer lugar, deberá conectar el disco de datos a la máquina virtual. Para hacerlo mediante el portal, consulte
How to attach a managed data disk in the Azure portal (Conexión de un disco de datos administrado en Azure
Portal).
Mover temporalmente el archivo pagefile.sys a la unidad C

1. Conexión a una máquina virtual.
2. Haga clic con el botón derecho en el menú Inicio y seleccione Sistema.
3. En el menú que aparece a la izquierda, seleccione Configuración avanzada del sistema.
4. En la sección Rendimiento, seleccione Configuración.
5. Seleccione la pestaña Opciones avanzadas .
6. En la sección Memoria virtual, seleccione Cambiar.
7. Seleccione la unidad C, luego haga clic en Tamaño administrado por el sistema y en Establecer.
8. Seleccione la unidad D, luego haga clic en Sin archivo de paginación y, a continuación, en Establecer.
9. Haga clic en Aplicar. Aparecerá una advertencia que indica que se debe reiniciar el equipo para que los
cambios entren en vigor.
10. Reinicie la máquina virtual.
Cambiar las letras de las unidades

1. Una vez que se reinicia la máquina virtual, vuelva a iniciar sesión en ella.
2. Haga clic en el menú Inicio, escribadiskmgmt.msc y presione Entrar. Se iniciará la Administración de discos.
3. Haga clic con el botón derecho en D, la unidad de almacenamiento temporal, y seleccione Cambiar la letra y
rutas de acceso de unidad.
4. En Letra de unidad, seleccione una unidad nueva como, por ejemplo, T y haga clic enAceptar.
5. Haga clic con el botón derecho en el disco de datos y seleccione Cambiar la letra y rutas de acceso de
unidad.
6. En Letra de unidad, seleccione la unidad D y haga clic enAceptar.
Devolver el archivo pagefile.sys a la unidad de almacenamiento

temporal
1. Haga clic con el botón derecho en el menú Inicio y seleccione Sistema.
2. En el menú que aparece a la izquierda, seleccione Configuración avanzada del sistema.
3. En la sección Rendimiento, seleccione Configuración.
4. Seleccione la pestaña Opciones avanzadas .
5. En la sección Memoria virtual, seleccione Cambiar.
6. Seleccione la unidad del sistema operativo C, haga clic en Sin archivo de paginación y luego en Establecer.
7. Seleccione la unidad de almacenamiento temporal T, haga clic en Tamaño administrado por el sistema y, a
continuación, en Establecer.
8. Haga clic en Aplicar. Aparecerá una advertencia que indica que se debe reiniciar el equipo para que los
cambios entren en vigor.
9. Reinicie la máquina virtual.
Pasos siguientes
Puede aumentar el almacenamiento disponible para la máquina virtual conectando un disco de datos adicional.
Cambio del conjunto de disponibilidad de una
máquina virtual Windows
En los pasos siguientes se describe cómo cambiar el conjunto de disponibilidad de una máquina virtual con Azure
PowerShell. Una máquina virtual solo puede agregarse a un conjunto de disponibilidad cuando se crea. Para
cambiar el conjunto de disponibilidad, debe eliminar la máquina virtual y volver a crearla.
Este artículo se probó por última vez el 12/02/2019 mediante Azure Cloud Shell y la versión 1.2.0 del módulo de
PowerShell de Az.
Cambio del conjunto de disponibilidad

El script siguiente proporciona un ejemplo de recopilación de la información necesaria: se elimina la máquina
virtual original y, luego, se vuelve a crear en un nuevo conjunto de disponibilidad.
# Set variables
$vmName = "myVM"
$newAvailSetName = "myAvailabilitySet"
# Get the details of the VM to be moved to the Availability Set

$originalVM = Get-AzVM `
-Name $vmName
# Create new availability set if it does not exist

$availSet = Get-AzAvailabilitySet `
-Name $newAvailSetName `
-ErrorAction Ignore
if (-Not $availSet) {
$availSet = New-AzAvailabilitySet `
-Location $originalVM.Location `
-Name $newAvailSetName `
-PlatformUpdateDomainCount 2 `
-Sku Aligned
}
# Remove the original VM

Remove-AzVM -ResourceGroupName $resourceGroup -Name $vmName
# Create the basic configuration for the replacement VM

$newVM = New-AzVMConfig `
-VMName $originalVM.Name `
-VMSize $originalVM.HardwareProfile.VmSize `
-AvailabilitySetId $availSet.Id
Set-AzVMOSDisk `
-VM $newVM -CreateOption Attach `
-ManagedDiskId $originalVM.StorageProfile.OsDisk.ManagedDisk.Id `
-Name $originalVM.StorageProfile.OsDisk.Name `
-Windows
# Add Data Disks

foreach ($disk in $originalVM.StorageProfile.DataDisks) {
Add-AzVMDataDisk -VM $newVM `
Add-AzVMDataDisk -VM $newVM `
-Name $disk.Name `
-ManagedDiskId $disk.ManagedDisk.Id `
-Caching $disk.Caching `
-Lun $disk.Lun `
-DiskSizeInGB $disk.DiskSizeGB `
-CreateOption Attach
}
# Add NIC(s) and keep the same NIC as primary

foreach ($nic in $originalVM.NetworkProfile.NetworkInterfaces) {
if ($nic.Primary -eq "True")
{
Add-AzVMNetworkInterface `
-VM $newVM `
-Id $nic.Id -Primary
}
else
{
Add-AzVMNetworkInterface `
-VM $newVM `
-Id $nic.Id
}
}
# Recreate the VM
New-AzVM `
-Location $originalVM.Location `
-VM $newVM `
-DisableBginfoExtension
Pasos siguientes
Agregue almacenamiento adicional a la máquina virtual mediante la adición de un disco de datosadicional.
Descargar la plantilla para una máquina virtual
Cuando se crea una máquina virtual en Azure mediante el portal o PowerShell, se crea automáticamente una
plantilla de Resource Manager. Puede usar esta plantilla para duplicar rápidamente una implementación. La
plantilla contiene información acerca de todos los recursos de un grupo de recursos. En el caso de una máquina
virtual, significa que la plantilla contiene todo lo que se crea para ayudar a la máquina virtual de ese grupo de
recursos, incluidos los recursos de red.
Descarga de la plantilla mediante el portal

1. Inicie sesión en Azure Portal.
4. Seleccione Exportar plantilla.
5. Seleccione Descargar en el menú de la parte superior y guarde el archivo .zip en el equipo local.
6. Abra el archivo .zip y extraiga los archivos en una carpeta. El archivo .zip contiene:
parameters.json
template.json
El archivo template.json es la plantilla.
Descarga de la plantilla mediante PowerShell

También puede descargar el archivo de plantilla .json mediante el cmdlet Export-AzResourceGroup. Puede usar el
parámetro -path para proporcionar el nombre de archivo y la ruta de acceso del archivo .json. En este ejemplo se
muestra cómo descargar la plantilla para el grupo de recursos denominado myResourceGroup en la carpeta
C:\users\public\downloads del equipo local.
Export-AzResourceGroup -ResourceGroupName "myResourceGroup" -Path "C:\users\public\downloads"
Pasos siguientes
Para más información sobre la implementación de recursos mediante plantillas, consulte el tutorial de plantillas de
Resource Manager.
Información general del agente de máquina virtual
de Azure
El agente de máquina virtual de Microsoft Azure (agente VM ) es un proceso ligero y seguro que administra la
interacción de máquinas virtuales (VM ) con el controlador de tejido de Azure. El agente de VM tiene un rol
principal que consiste en habilitar y ejecutar extensiones de máquina virtual de Azure. Las extensiones de máquina
virtual habilitan la configuración posterior a la implementación de máquinas virtuales, como la instalación y la
configuración de software. Las extensiones de máquina virtual también habilitan características de recuperación,
como el restablecimiento de la contraseña administrativa de una máquina virtual. Sin el agente de máquina virtual
de Azure, no se pueden ejecutar extensiones de máquina virtual.
En este artículo se describe la instalación, la detección y la eliminación del agente de máquina virtual de Azure.
Instalar el agente de VM
Imagen de Azure Marketplace
El agente de máquina virtual de Azure se instala de forma predeterminada en cualquier máquina virtual de
Windows implementada a partir de una imagen de Azure Marketplace. Al implementar una imagen de Azure
Marketplace desde el portal, PowerShell, la interfaz de la línea de comandos o una plantilla de Azure Resource
Manager, también se instalará el agente de máquina virtual de Azure.
El paquete de Windows Guest Agent se divide en dos partes:
Agente de aprovisionamiento (PA)
Windows Guest Agent (WinGA)
Para arrancar una máquina virtual debe tener el agente de aprovisionamiento instalado en la máquina virtual,
pero no es necesario instalar WinGA. En tiempo de implementación de la máquina virtual, puede seleccionar no
instalar WinGA. En el ejemplo siguiente se muestra cómo seleccionar la opción provisionVmAgent con una
plantilla de Azure Resource Manager:
"resources": [{
"name": "[parameters('virtualMachineName')]",
"dependsOn": ["[concat('Microsoft.Network/networkInterfaces/', parameters('networkInterfaceName'))]"],
"properties": {
"osProfile": {
"computerName": "[parameters('virtualMachineName')]",
"adminPassword": "[parameters('adminPassword')]",
"windowsConfiguration": {
"provisionVmAgent": "false"
}
Si no tiene instalados los agentes, no puede usar algunos servicios de Azure, como Azure Backup o Azure
Security. Estos servicios requieren una extensión para instalarse. Si ha implementado una máquina virtual sin
WinGA, puede instalar más tarde la versión más reciente del agente.
Instalación manual
El agente de máquina virtual de Windows puede instalarse manualmente con un paquete de Windows Installer. Es
posible que sea necesaria la instalación manual cuando se crea una imagen de máquina virtual personalizada que
se implementa en Azure. Para instalar manualmente el agente de máquina virtual de Windows, descargue el
instalador del agente de máquina virtual. El agente de máquina virtual solo se admite en Windows Server 2008
R2 y posterior.
Para instalar el agente de máquina virtual, haga doble clic en el archivo de Windows Installer. Para una instalación
automatizada o desatendida del agente de máquina virtual, ejecute el comando siguiente:
msiexec.exe /i WindowsAzureVmAgent.2.7.1198.778.rd_art_stable.160617-1120.fre /quiet
Requisitos previos
El agente de VM de Windows necesita como mínimo Windows Server 2008 R2 (64 bits) para ejecutarse, con .NET
Framework 4.0. Consulte Versión mínima admitida para los agentes de la máquina virtual en Azure.
Detección del agente de VM

PowerShell
El módulo de PowerShell de Azure Resource Manager puede usarse para recuperar información sobre máquinas
virtuales de Azure. Para ver información sobre una VM, como el estado de aprovisionamiento para el agente de
VM de Azure, use Get-AzVM:
Get-AzVM
El siguiente ejemplo condensado de salida muestra la propiedad ProvisionVMAgent anidada dentro de OSProfile.
Esta propiedad se puede usar para determinar si el agente de VM se ha implementado en la VM:
OSProfile :
ComputerName : myVM
AdminUsername : myUserName
WindowsConfiguration :
ProvisionVMAgent : True
EnableAutomaticUpdates : True
El siguiente script se puede usar para devolver una lista concisa de nombres de máquinas virtuales y el estado del
agente de máquina virtual:
$vms = Get-AzVM
foreach ($vm in $vms) {

$agent = $vm | Select -ExpandProperty OSProfile | Select -ExpandProperty Windowsconfiguration | Select
ProvisionVMAgent
Write-Host $vm.Name $agent.ProvisionVMAgent
}
Detección manual
Cuando inicia sesión en una máquina virtual de Windows, el Administrador de tareas se puede usar para examinar
los procesos en ejecución. Para comprobar el agente de máquina virtual de Azure, abra el Administrador de tareas,
haga clic en la pestaña Detalles y busque el nombre de proceso WindowsAzureGuestAgent.exe. La presencia
de este proceso indica que el agente de VM está instalado.
Actualización del agente de VM

El agente de VM de Azure para Windows se actualiza automáticamente. A medida que se implementan nuevas
máquinas virtuales en Azure, reciben el agente de máquina virtual más reciente en tiempo de aprovisionamiento
de máquina virtual. Las imágenes de máquina virtual personalizadas se deben actualizar manualmente para que
incluyan el nuevo agente de máquina virtual en tiempo de creación de la imagen.
Recopilación de registros automáticos de Windows Guest Agent

Windows Guest Agent tiene una característica para recopilar automáticamente algunos registros. Esta
característica está controlada por el proceso CollectGuestLogs.exe. Existe tanto para los servicios en la nube PaaS
como para las máquinas virtuales de IaaS, y su objetivo es recopilar rápida y automáticamente algunos registros
de diagnóstico de una máquina virtual, de modo que se puedan usar para realizar un análisis sin conexión. Los
registros recopilados son registros de eventos, registros del sistema operativo, registros de Azure y algunas claves
del Registro. Se genera un archivo ZIP que se transfiere al host de la máquina virtual. Este archivo ZIP puede ser
consultado por los equipos de ingeniería y los profesionales de soporte técnico para investigar problemas en la
solicitud del cliente propietario de la máquina virtual.
Pasos siguientes
Para más información sobre las extensiones de máquina virtual, consulte Características y extensiones de las
Instrucciones para mitigar vulnerabilidades frente a
ataques de canal lateral de ejecución especulativa en
Azure
Última actualización del documento: 12 de noviembre 2019 10:00 h PST.

La divulgación de una nueva clase de vulnerabilidades de CPU, conocidas como ataques de canal lateral de
ejecución especulativa, han generado preguntas de los clientes que buscan mayor claridad.
Microsoft ha implementado mitigaciones en todos nuestros servicios en la nube. La infraestructura que ejecuta
Azure y aísla las cargas de trabajo de los clientes entre sí está protegida. Esto significa que un atacante potencial
que use la misma infraestructura no puede atacar su aplicación mediante estas vulnerabilidades.
Azure utiliza un mantenimiento con conservación de memoria siempre que es posible para minimizar el impacto
en el cliente y eliminar la necesidad de reinicios. Azure seguirá utilizando estos métodos al realizar actualizaciones
del host en todo el sistema y proteger a los clientes.
Encontrará más información acerca de cómo integrar la seguridad en todos los aspectos de Azure en el sitio de
documentación de Azure Security Center.
NOTE
Desde que este documento se publicó por primera vez, se han divulgado varias variantes de esta clase de vulnerabilidad.
Microsoft continúa realizando grandes esfuerzos por proteger a nuestros clientes y proporcionarles orientación. Esta página
se actualizará a medida que se publiquen más correcciones.
El 12 de noviembre de 2019, Intel publicó un aviso técnico sobre la vulnerabilidad anulación asincrónica de transacciones
(TAA) de Intel® Extensiones de sincronización transaccional (Intel® TSX) al que se le asignó CVE-2019-11135. Esta
vulnerabilidad afecta a los procesadores Intel® Core® y los procesadores Intel® Xeon®. Microsoft Azure ha publicado
actualizaciones del sistema operativo y está implementando nuevo microcódigo, a medida que Intel reveló lo anterior, en toda
nuestra flota para proteger a nuestros clientes contra estos nuevos puntos vulnerables. Azure está trabajando estrechamente
con Intel para probar y validar el nuevo microcódigo antes de su lanzamiento oficial en la plataforma.
Los clientes que ejecutan código que no es de confianza dentro de su máquina virtual deben tomar medidas para
protegerse frente a estos puntos vulnerables; para ello, lea a continuación para obtener instrucciones acerca de todas las
vulnerabilidades de canal lateral de ejecución especulativa (ADV de Avisos de Microsoft 180002, 180018 y 190013).
Otros clientes deben evaluar estos puntos vulnerables desde la perspectiva de la defensa en profundidad y considerar las
implicaciones en la seguridad y el rendimiento de la configuración que han elegido.
Mantener actualizados los sistemas operativos

Aunque no se necesita una actualización del sistema operativo para aislar de otros clientes las aplicaciones que se
ejecutan en Azure, mantener el software actualizado siempre es un procedimiento recomendado. Los últimos
paquetes acumulativos de actualizaciones de seguridad para Windows contienen mitigaciones para varias
vulnerabilidades de canal lateral de ejecución especulativa. De forma similar, las distribuciones de Linux han
publicado varias actualizaciones para corregir estas vulnerabilidades. Estas son las acciones recomendadas para
actualizar el sistema operativo:
OFERTA ACCIÓN RECOMENDADA
Azure Cloud Services Habilite las actualizaciones automáticas o asegúrese de que

está ejecutando la versión más reciente del sistema operativo
invitado.
Máquinas virtuales Linux en Azure Instale las actualizaciones de su proveedor de sistema

operativo. Para más información, consulte Linux más adelante
en este documento.
Máquinas virtuales Windows en Azure Instale las últimas actualizaciones acumulativas de seguridad.
Otros servicios PaaS de Azure No es necesaria ninguna acción para los clientes que usan
estos servicios. Azure mantiene actualizadas las versiones de
sistema operativo de forma automática.
Instrucciones adicionales si está ejecutando código que no es de

confianza
Los clientes que permiten a los usuarios que no son de confianza ejecutar código arbitrario tal vez deseen
implementar algunas características de seguridad adicionales en las máquinas virtuales o en los servicios en la
nube de Azure. Estas características protegen frente a los vectores de divulgación entre procesos que describen
varias vulnerabilidades de ejecución especulativa.
Escenarios de ejemplo donde se recomiendan las características de seguridad adicionales:
Permite la ejecución de código que no es de confianza en la máquina virtual.
Por ejemplo, permite que uno de sus clientes cargue un archivo binario o un script que, a continuación,
se ejecutará en la aplicación.
Permite iniciar sesión en la máquina virtual con cuentas con privilegios reducidos a usuarios que no son de
confianza.
Por ejemplo, permite iniciar sesión en una de las máquinas virtuales mediante escritorio remoto o SSH a
un usuario con privilegios reducidos.
Permite acceder a las máquinas virtuales implementadas mediante virtualización anidada a usuarios que no son
de confianza.
Por ejemplo, controla el host de Hyper-V, pero asigna las máquinas virtuales a usuarios que no son de
confianza.
Los clientes que no implementan un escenario relacionado con código que no es de confianza no necesitan
habilitar estas características de seguridad adicionales.
Habilitación de la seguridad adicional

Puede habilitar características de seguridad adicionales en la máquina virtual o en el servicio en la nube si ejecuta
código que no sea de confianza. Al mismo tiempo, asegúrese de que el sistema operativo está actualizado para
habilitar las características de seguridad dentro de la máquina virtual o el servicio en la nube
Windows
El sistema operativo de destino debe estar actualizado para habilitar estas características de seguridad adicionales.
Aunque hay habilitadas numerosas mitigaciones del canal lateral de ejecución especulativa de forma
predeterminada, las características adicionales que se describen aquí deben habilitarse manualmente y pueden
afectar al rendimiento.
Paso 1: deshabilite la característica de hyper-threading en la máquina virtual. Los clientes que ejecutan
código que no es de confianza en una máquina virtual de hyper-threading deben deshabilitarlo o pasar a un
tamaño de máquina virtual que no sea hyper-threading. Remítase a este documento para obtener una lista de
tamaños de máquina virtual de hyper-threading (donde la proporción de vCPU a Core es 2:1). Para comprobar si
la máquina virtual tiene habilitada la característica de hyper-threading, consulte el siguiente script mediante la línea
de comandos de Windows desde la máquina virtual.
Escriba wmic para especificar la interfaz interactiva. A continuación, escriba lo siguiente para ver la cantidad de
procesadores físicos y lógicos en la máquina virtual.
CPU Get NumberOfCores,NumberOfLogicalProcessors /Format:List
Si el número de procesadores lógicos es mayor que el de procesadores físicos (núcleos), la característica de hyper-
threading está habilitada. Si está ejecutando una máquina virtual de hyper-threading, póngase en contacto con el
soporte técnico de Azure para deshabilitar la característica de hyper-threading. Una vez que el hyper-threading esté
deshabilitado, se requerirá un reinicio completo de la máquina virtual. Consulte Número de núcleos para
saber por qué se reduce el número de núcleos de máquina virtual.
Paso 2: A la vez que el paso 1, siga las instrucciones descritas en KB4072698 para comprobar que las protecciones
se habilitan con el módulo de PowerShell SpeculationControl.
NOTE
Si descargó este módulo anteriormente, deberá instalar la versión más reciente.
La salida del script de PowerShell debe tener los siguientes valores para validar las protecciones habilitadas frente
a estos puntos vulnerables:
Windows OS support for branch target injection mitigation is enabled: True

Windows OS support for kernel VA shadow is enabled: True
Windows OS support for speculative store bypass disable is enabled system-wide: False
Windows OS support for L1 terminal fault mitigation is enabled: True
Windows OS support for MDS mitigation is enabled: True
Windows OS support for TAA mitigation is enabled: True
Si el resultado muestra MDS mitigation is enabled: False , póngase en contacto con el soporte técnico de Azure
para conocer las opciones de mitigación disponibles.
Paso 3: Para habilitar la compatibilidad del sistema operativo con la copia paralela de direcciones virtuales de
kernel (KVAS ) y la inserción de destino de rama (BTI), siga las instrucciones de KB4072698 para habilitar las
protecciones con las claves del Registro de Session Manager . Es necesario reiniciar.
Paso 4: Para las implementaciones que usan la virtualización anidada (solo D3 y E3): Estas instrucciones se aplican
dentro de la máquina virtual que se va a usar como un host de Hyper-V.
1. Siga las instrucciones descritas en el artículo KB4072698 para habilitar las protecciones mediante las claves del
Registro MinVmVersionForCpuBasedMitigations .
2. Establezca el tipo de programador del hipervisor en Core mediante las instrucciones descritas aquí.
Linux
Se requiere que el sistema operativo de destino esté completamente actualizado para habilitar el conjunto de
características de seguridad adicionales. Algunas de las mitigaciones estarán habilitadas de forma predeterminada.
La siguiente sección describe las características que están desactivadas de forma predeterminada y sujetas a la
compatibilidad de hardware (microcódigo). La habilitación de estas características puede afectar al rendimiento.
Consulte la documentación del proveedor de su sistema operativo para más instrucciones
Paso 1: deshabilite la característica de hyper-threading en la máquina virtual. Los clientes que ejecutan
código que no es de confianza en una máquina virtual de hyper-threading deben deshabilitarlo o pasar a una
máquina virtual que no sea hyper-threading. Remítase a este documento para obtener una lista de tamaños de
máquina virtual de hyper-threading (donde la proporción de vCPU a Core es 2:1). Para comprobar si está
ejecutando una máquina virtual de hyper-threading, ejecute el comando lscpu en la máquina virtual de Linux.
Si Thread(s) per core = 2 , el hyper-threading se ha habilitado.
Si Thread(s) per core = 1 , el hyper-threading se ha deshabilitado.
Salida de ejemplo para una máquina virtual con hyper-threading habilitado:
CPU Architecture: x86_64

CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Si está ejecutando una máquina virtual de hyper-threading, póngase en contacto con el soporte técnico de Azure
para deshabilitar la característica de hyper-threading. Una vez que el hyper-threading esté deshabilitado, se
requerirá un reinicio completo de la máquina virtual. Consulte Número de núcleos para saber por qué se
reduce el número de núcleos de máquina virtual.
Paso 2: Para mitigar cualquiera de los siguientes puntos vulnerables de canal lateral de ejecución especulativa,
consulte la documentación del proveedor de su sistema operativo:
RedHat y CentOS
SUSE
Ubuntu
Recuento de núcleos
Cuando se crea una máquina virtual de hyper-threading, Azure asigna dos subprocesos por núcleo, que se
denominan vCPU. Cuando el hyper-threading está deshabilitado, Azure quita un subproceso y usa los núcleos de
subprocesos únicos (núcleos físicos). La proporción de vCPU y CPU es 2:1, de modo que, una vez que el hyper-
threading se deshabilite, el número de CPU en la máquina virtual aparecerá reducido a la mitad. Por ejemplo, una
máquina virtual D8_v3 es una máquina virtual de hyper-threading que se ejecuta en 8 vCPU (2 subprocesos por
núcleo, por 4 núcleos). Cuando el hyper-threading se deshabilite, las CPU caerán hasta 4 núcleos físicos con
1 subproceso por núcleo.
Pasos siguientes
Este artículo proporciona instrucciones para los siguientes ataques de canal lateral de ejecución especulativa que
afectan a muchos de los procesadores modernos:
Spectre Meltdown:
CVE -2017-5715: inserción de destino de rama (BTI)
CVE -2017-5754: aislamiento de tabla de páginas de kernel (KPTI)
CVE -2018-3639: omisión especulativa de almacén (KPTI)
CVE -2019-1125: información del kernel de Windows, variante de Spectre variante 1
Error de terminal L1 (L1TF ):
CVE -2018-3615: extensiones de protección de software de Intel (Intel SGX)
CVE -2018-3620: sistemas operativos (SO ) y modo de administración del sistema (SMM )
CVE -2018-3646: afecta a Virtual Machine Manager (VMM )
Muestreo de datos de microarquitectura:
CVE -2019-11091: Memoria sin caché de muestreo de datos de microarquitectura (MDSUM )
CVE -2018-12126: Muestreo de datos de búfer de almacén de microarquitectura (MSBDS )
CVE -2018-12127: Muestreo de datos de puerto de carga microarquitectura (MLPDS )
CVE -2018-12130: Muestreo de datos de búfer de relleno de microarquitectura (MFBDS )
Anulación asincrónica de transacciones de Extensiones de sincronización transaccional (Intel® TSX):
CVE -2019-11135: asincrónica de transacciones de TSX (TAA)
Servicio de metadatos de instancia de Azure
El servicio de metadatos de instancia de Azure proporciona información sobre instancias de máquina virtual en
ejecución que pueden usarse para administrar y configurar las máquinas virtuales. Esto incluye información como
SKU, configuración de red y eventos de mantenimiento próximos. Para más información sobre el tipo de
información que hay disponible, vea API de metadatos.
El servicio de metadatos de instancia de Azure es un punto de conexión REST al que pueden tener acceso todas
las máquinas virtuales IaaS creadas a través de Azure Resource Manager. El punto de conexión está disponible en
una dirección IP no enrutable conocida ( 169.254.169.254 ) a la que solo se puede tener acceso desde dentro de la
máquina virtual.
IMPORTANT
Este servicio está disponible con carácter general en todas las regiones de Azure. Recibe actualizaciones periódicas para
exponer información nueva sobre instancias de máquina virtual. En esta página se reflejan las API de metadatos actualizadas
que hay disponibles.
Disponibilidad del servicio

El servicio está disponible con carácter general en las regiones de Azure. Puede que no todas las versiones de API
estén disponibles en todas las regiones de Azure.
REGIONS ¿DISPONIBILIDAD? VERSIONES COMPATIBLES
Todas las regiones globales de Azure Disponibilidad general 2017-04-02, 2017-08-01, 2017-12-
disponibles con carácter general 01, 2018-02-01, 2018-04-02, 2018-
10-01, 2019-02-01, 2019-03-11,
2019-04-30, 2019-06-01, 2019-06-04
Azure Government Disponibilidad general 2017-04-02, 2017-08-01, 2017-12-

01, 2018-02-01, 2018-04-02, 2018-
10-01, 2019-02-01, 2019-03-11,
2019-04-30
Azure en China Disponibilidad general 2017-04-02, 2017-08-01, 2017-12-

01, 2018-02-01, 2018-04-02, 2018-
10-01, 2019-02-01, 2019-03-11,
2019-04-30
Azure Alemania Disponibilidad general 2017-04-02, 2017-08-01, 2017-12-

01, 2018-02-01, 2018-04-02, 2018-
10-01, 2019-02-01, 2019-03-11,
2019-04-30
Esta tabla cambia cuando hay actualizaciones del servicio o cuando hay nuevas versiones compatibles disponibles.
Para probar el servicio de metadatos de instancia, cree una máquina virtual desde Azure Resource Manager o
Azure Portal en las regiones anteriores, y siga los ejemplos siguientes.
Uso
Control de versiones
Instance Metadata Service tiene versiones y es obligatorio especificar la versión de la API en la solicitud HTTP.
Puede ver las versiones más recientes enumeradas en esta tabla de disponibilidad.
A medida que se agreguen versiones más recientes, todavía se podrá acceder a las versiones anteriores por
motivos de compatibilidad si los scripts tienen dependencias en formatos de datos específicos.
Cuando no se especifica ninguna versión, se devuelve un error con una lista de las versiones más recientes que
son compatibles.
NOTE
La respuesta es una cadena JSON. La respuesta de ejemplo siguiente se ha impreso correctamente para mejorar la
legibilidad.
Solicitud
curl -H Metadata:true "http://169.254.169.254/metadata/instance"
Respuesta
{
"error": "Bad request. api-version was not specified in the request. For more information refer to
aka.ms/azureimds",
"newest-versions": [
"2018-10-01",
"2018-04-02",
"2018-02-01"
]
}
Uso de encabezados
Al consultar el servicio de metadatos de instancia, debe proporcionar el encabezado Metadata: true para
asegurarse de que la solicitud no se ha redirigido de manera involuntaria.
Recuperar metadatos
Los metadatos de instancia están disponibles para ejecutar máquinas virtuales creadas o administradas mediante
Azure Resource Manager. Para tener acceso a todas las categorías de datos de una instancia de máquina virtual,
use la solicitud siguiente:
curl -H Metadata:true "http://169.254.169.254/metadata/instance?api-version=2017-08-01"
NOTE
Todas las consultas de metadatos de instancia distinguen mayúsculas de minúsculas.
Salida de datos
De forma predeterminada, el servicio de metadatos de instancia devuelve datos en formato JSON (
Content-Type: application/json ). Pero las distintas API devuelven los datos en formatos diferentes si se solicita.
En la tabla siguiente se muestra una referencia de otros formatos de datos que las API pueden admitir.
API FORMATO PREDETERMINADO DE DATOS OTROS FORMATOS
/instance json text
/scheduledevents json None
/attested json None
Para acceder a un formato de respuesta que no sea el predeterminado, especifique el formato solicitado como un
parámetro de cadena de consulta en la solicitud. Por ejemplo:
curl -H Metadata:true "http://169.254.169.254/metadata/instance?api-version=2017-08-01&format=text"
NOTE
Para los nodos hoja, format=json no funciona. Para estas consultas, format=text debe especificarse explícitamente si el
formato predeterminado es JSON.
Seguridad
El punto de conexión del servicio de metadatos de instancia solo es accesible desde la instancia de máquina
virtual en ejecución en una dirección IP no enrutable. Además, el servicio rechaza cualquier solicitud que tenga un
encabezado X-Forwarded-For . Las solicitudes tienen que incluir también un encabezado Metadata: true para
garantizar que la solicitud actual esté dirigida directamente y no como parte de un redireccionamiento accidental.
Error
Si no se encuentra un elemento de datos o hay una solicitud con formato incorrecto, el servicio de metadatos de
instancia devuelve errores HTTP estándar. Por ejemplo:
CÓDIGO DE ESTADO HTTP MOTIVO
200 OK
400 - Solicitud incorrecta Falta el encabezado Metadata: true o el formato al

consultar un nodo hoja
404 No encontrado El elemento solicitado no existe
405 Método no permitido Solo se admiten solicitudes GET y POST
429 Demasiadas solicitudes La API es compatible actualmente con un máximo de cinco

consultas por segundo
500 Error de servicio Vuelva a intentarlo más tarde
Ejemplos
NOTE
Todas las respuestas de las API son cadenas JSON. Todas las respuestas de ejemplo siguientes se han imprimido
correctamente para mejorar la legibilidad.
Recuperación de información de red

Solicitud
curl -H Metadata:true "http://169.254.169.254/metadata/instance/network?api-version=2017-08-01"
Respuesta
NOTE
legibilidad.
{
"interface": [
{
"ipv4": {
"ipAddress": [
{
"publicIpAddress": "X.X.X.X"
}
],
"subnet": [
{
"address": "10.1.0.0",
"prefix": "24"
}
]
},
"ipv6": {
"ipAddress": []
},
"macAddress": "000D3AF806EC"
}
]
}
Recuperación de dirección IP pública
curl -H Metadata:true
"http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-
version=2017-08-01&format=text"
Recuperación de todos los metadatos para una instancia

Solicitud
curl -H Metadata:true "http://169.254.169.254/metadata/instance?api-version=2019-03-11"
Respuesta
NOTE
legibilidad.
{
"compute": {
"azEnvironment": "AzurePublicCloud",
"customData": "",
"location": "westus",
"name": "jubilee",
"offer": "Windows-10",
"osType": "Windows",
"placementGroupId": "",
"plan": {
"name": "",
"product": "",
"publisher": ""
},
"platformFaultDomain": "1",
"platformUpdateDomain": "1",
"provider": "Microsoft.Compute",
"publicKeys": [],
"publisher": "MicrosoftWindowsDesktop",
"resourceGroupName": "myrg",
"resourceId": "/subscriptions/xxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxx/resourceGroups/myrg/providers/Microsoft.Compute/virtualMachines/negasonic",
"sku": "rs4-pro",
"subscriptionId": "xxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx",
"tags": "Department:IT;Environment:Prod;Role:WorkerRole",
"version": "17134.345.59",
"vmId": "13f56399-bd52-4150-9748-7190aae1ff21",
"vmScaleSetName": "",
"vmSize": "Standard_D1",
"zone": "1"
},
"network": {
"interface": [
{
"ipv4": {
"ipAddress": [
{
}
],
"subnet": [
{
"address": "10.1.2.0",
"prefix": "24"
}
]
},
"ipv6": {
"ipAddress": []
},
"macAddress": "000D3A36DDED"
}
]
}
}
Recuperación de metadatos en una máquina virtual con Windows

Solicitud
Los metadatos de instancia se pueden recuperar en Windows a través del programa curl :
curl -H @{'Metadata'='true'} http://169.254.169.254/metadata/instance?api-version=2019-03-11 | select -

ExpandProperty Content
O a través del cmdlet de PowerShell Invoke-RestMethod :
Invoke-RestMethod -Headers @{"Metadata"="true"} -URI http://169.254.169.254/metadata/instance?api-

version=2019-03-11 -Method get
Respuesta
NOTE
legibilidad.
{
"compute": {
"azEnvironment": "AzurePublicCloud",
"customData": "",
"location": "westus",
"name": "SQLTest",
"offer": "SQL2016SP1-WS2016",
"placementGroupId": "",
"plan": {
"name": "",
"product": "",
"publisher": ""
},
"provider": "Microsoft.Compute",
"publicKeys": [],
"publisher": "MicrosoftSQLServer",
"resourceGroupName": "myrg",
"resourceId": "/subscriptions/xxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxx/resourceGroups/myrg/providers/Microsoft.Compute/virtualMachines/negasonic",
"sku": "Enterprise",
"subscriptionId": "xxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx",
"tags": "Department:IT;Environment:Test;Role:WebRole",
"version": "13.0.400110",
"vmId": "453945c8-3923-4366-b2d3-ea4c80e9b70e",
"vmScaleSetName": "",
"vmSize": "Standard_DS2",
"zone": ""
},
"network": {
"interface": [
{
"ipv4": {
"ipAddress": [
{
}
],
"subnet": [
{
"address": "10.0.1.0",
"prefix": "24"
}
]
},
"ipv6": {
"ipAddress": []
},
"macAddress": "002248020E1E"
}
]
}
}
API de metadatos
Las siguientes API están disponibles a través del punto de conexión de metadatos:
DATOS DESCRIPCIÓN VERSIÓN DE INTRODUCCIÓN
attested Consulte Datos atestiguados 2018-10-01

identity Identidades administradas de recursos 2018-02-01

de Azure. Consulte Obtener un token
de acceso
instance Vea API de instancia. 2017-04-02
scheduledevents Consulte Scheduled Events. 2017-08-01
API de instancia
L a s si g u i e n t e s c a t e g o r í a s d e p r o c e so s e st á n d i sp o n i b l e s a t r a v é s d e l a A P I d e i n st a n c i a :
NOTE
Mediante el punto de conexión de metadatos, se accede a las siguientes categorías a través de la instancia y los procesos:
azEnvironment Entorno de Azure donde se está 2018-10-01

ejecutando la máquina virtual
customData Vea Datos personalizados. 01-02-2019
location La región de Azure donde se ejecuta la 2017-04-02

máquina virtual
Nombre Nombre de la máquina virtual 2017-04-02
offer Ofrece información de la imagen de la 2017-04-02

máquina virtual y solo está presente
para imágenes implementadas desde la
galería de imágenes de Azure.
osType Linux o Windows 2017-04-02
placementGroupId Grupo de selección de ubicación de su 2017-08-01

conjunto de escalado de máquina
virtual
plan Plan que contiene el nombre, el 2018-04-02

producto y el editor de una máquina
virtual si es una imagen de Azure
Marketplace
platformUpdateDomain El dominio de actualización en que se 2017-04-02

ejecuta la máquina virtual.
platformFaultDomain El dominio de error en que se ejecuta la 2017-04-02

máquina virtual.
provider Proveedor de la máquina virtual 2018-10-01
publicKeys Colección de claves públicas asignada a 2018-04-02

la máquina virtual y rutas de acceso
publisher Publicador de la imagen de VM 2017-04-02
resourceGroupName Grupo de recursos para su máquina 2017-08-01

virtual
resourceId El identificador completo del recurso 2019-03-11
sku SKU específica de la imagen de VM 2017-04-02
subscriptionId Suscripción de Azure para la máquina 2017-08-01

virtual
etiquetas Etiquetas para su máquina virtual 2017-08-01
tagsList Etiquetas con formato de matriz de 2019-06-04

JSON para facilitar el análisis mediante
programación
version Versión de la imagen de máquina 2017-04-02

virtual
vmId Identificador único para la máquina 2017-04-02

virtual.
vmScaleSetName Nombre del conjunto de escalado de 2017-12-01

máquina virtual de conjunto de
escalado de la máquina virtual
vmSize Tamaño de VM 2017-04-02
zona Zona de disponibilidad de la máquina 2017-12-01

virtual
L a s si g u i e n t e s c a t e g o r í a s d e r e d e s e st á n d i sp o n i b l e s a t r a v é s d e l a A P I d e i n st a n c i a :
NOTE
Mediante el punto de conexión de metadatos, se accede a las siguientes categorías a través de la instancia, la red o la
interfaz.
ipv4/privateIpAddress Dirección IPv4 local de la máquina 2017-04-02

virtual
ipv4/publicIpAddress Dirección IPv4 pública de la máquina 2017-04-02

virtual
subnet/address Dirección de subred de la máquina 2017-04-02

virtual
subnet/prefix Prefijo de la subred, ejemplo, 24 2017-04-02

ipv6/ipAddress Dirección IPv6 local de la máquina 2017-04-02

virtual
macAddress Dirección de MAC de la VM 2017-04-02
Datos atestiguados
Instance Metadata responde en el punto de conexión HTTP en 169.254.169.254. Parte del escenario que sirve
Instance Metadata Service está destinado a proporcionar la garantía de que los datos respondidos vienen de
Azure. Firmamos una parte de esta información para que las imágenes de Marketplace puedan tener la seguridad
de que su imagen se ejecuta en Azure.
Datos atestiguados de ejemplo
NOTE
Todas las respuestas de las API son cadenas JSON. Las siguientes respuestas de ejemplo se han impreso correctamente para
facilitar su lectura.
Solicitud
curl -H Metadata:true "http://169.254.169.254/metadata/attested/document?api-version=2018-10-

01&nonce=1234567890"
Api-version es un campo obligatorio. Consulte la sección de disponibilidad del servicio para ver las versiones de
API admitidas. Nonce es una cadena de 10 dígitos opcional que se proporciona. Nonce se puede usar para
realizar un seguimiento de la solicitud y, si no se proporciona, la marca de tiempo UTC actual se devuelve en la
cadena codificada de respuesta.
Respuesta
NOTE
legibilidad.
{
"encoding":"pkcs7","signature":"MIIEEgYJKoZIhvcNAQcCoIIEAzCCA/8CAQExDzANBgkqhkiG9w0BAQsFADCBugYJKoZIhvcNAQcBoI
GsBIGpeyJub25jZSI6IjEyMzQ1NjY3NjYiLCJwbGFuIjp7Im5hbWUiOiIiLCJwcm9kdWN0IjoiIiwicHVibGlzaGVyIjoiIn0sInRpbWVTdGFt
cCI6eyJjcmVhdGVkT24iOiIxMS8yMC8xOCAyMjowNzozOSAtMDAwMCIsImV4cGlyZXNPbiI6IjExLzIwLzE4IDIyOjA4OjI0IC0wMDAwIn0sIn
ZtSWQiOiIifaCCAj8wggI7MIIBpKADAgECAhBnxW5Kh8dslEBA0E2mIBJ0MA0GCSqGSIb3DQEBBAUAMCsxKTAnBgNVBAMTIHRlc3RzdWJkb21h
aW4ubWV0YWRhdGEuYXp1cmUuY29tMB4XDTE4MTEyMDIxNTc1N1oXDTE4MTIyMDIxNTc1NlowKzEpMCcGA1UEAxMgdGVzdHN1YmRvbWFpbi5tZX
RhZGF0YS5henVyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAML/tBo86ENWPzmXZ0kPkX5dY5QZ150mA8lommszE71x2sCLonzv
4/UWk4H+jMMWRRwIea2CuQ5RhdWAHvKq6if4okKNt66fxm+YTVz9z0CTfCLmLT+nsdfOAsG1xZppEapC0Cd9vD6NCKyE8aYI1pliaeOnFjG0Wv
MY04uWz2MdAgMBAAGjYDBeMFwGA1UdAQRVMFOAENnYkHLa04Ut4Mpt7TkJFfyhLTArMSkwJwYDVQQDEyB0ZXN0c3ViZG9tYWluLm1ldGFkYXRh
LmF6dXJlLmNvbYIQZ8VuSofHbJRAQNBNpiASdDANBgkqhkiG9w0BAQQFAAOBgQCLSM6aX5Bs1KHCJp4VQtxZPzXF71rVKCocHy3N9PTJQ9Fpnd
+bYw2vSpQHg/AiG82WuDFpPReJvr7Pa938mZqW9HUOGjQKK2FYDTg6fXD8pkPdyghlX5boGWAMMrf7bFkup+lsT+n2tRw2wbNknO1tQ0wICtqy
2VqzWwLi45RBwTGB6DCB5QIBATA/MCsxKTAnBgNVBAMTIHRlc3RzdWJkb21haW4ubWV0YWRhdGEuYXp1cmUuY29tAhBnxW5Kh8dslEBA0E2mIB
J0MA0GCSqGSIb3DQEBCwUAMA0GCSqGSIb3DQEBAQUABIGAld1BM/yYIqqv8SDE4kjQo3Ul/IKAVR8ETKcve5BAdGSNkTUooUGVniTXeuvDj5Nk
mazOaKZp9fEtByqqPOyw/nlXaZgOO44HDGiPUJ90xVYmfeK6p9RpJBu6kiKhnnYTelUk5u75phe5ZbMZfBhuPhXmYAdjc7Nmw97nx8NnprQ="
}
El blob de firma es una versión con la firma pkcs7 del documento. Contiene el certificado usado para firmar
junto con detalles de la máquina virtual como vmld, nonce, subscriptionId y timeStamp para la creación y
expiración del documento y la información del plan sobre la imagen. La información del plan solo se rellena
para las imágenes de Azure Marketplace. El certificado se puede extraer de la respuesta y usarse para validar
que la respuesta es válida y viene de Azure.
Recuperación de metadatos atestiguados en una máquina virtual Windows

Solicitud
Los metadatos de instancia se pueden recuperar en Windows a través de la utilidad curl de PowerShell:
curl -H @{'Metadata'='true'} "http://169.254.169.254/metadata/attested/document?api-version=2018-10-

01&nonce=1234567890" | select -ExpandProperty Content
O bien a través del cmdlet Invoke-RestMethod :
Invoke-RestMethod -Headers @{"Metadata"="true"} -URI "http://169.254.169.254/metadata/attested/document?api-

version=2018-10-01&nonce=1234567890" -Method get
Api-version es un campo obligatorio. Consulte la sección de disponibilidad del servicio para ver las versiones de
API admitidas. Nonce es una cadena de 10 dígitos opcional que se proporciona. Nonce se puede usar para
realizar un seguimiento de la solicitud y, si no se proporciona, la marca de tiempo UTC actual se devuelve en la
cadena codificada de respuesta.
Respuesta
NOTE
legibilidad.
{
"encoding":"pkcs7","signature":"MIIEEgYJKoZIhvcNAQcCoIIEAzCCA/8CAQExDzANBgkqhkiG9w0BAQsFADCBugYJKoZIhvcNAQcBoI
GsBIGpeyJub25jZSI6IjEyMzQ1NjY3NjYiLCJwbGFuIjp7Im5hbWUiOiIiLCJwcm9kdWN0IjoiIiwicHVibGlzaGVyIjoiIn0sInRpbWVTdGFt
cCI6eyJjcmVhdGVkT24iOiIxMS8yMC8xOCAyMjowNzozOSAtMDAwMCIsImV4cGlyZXNPbiI6IjExLzIwLzE4IDIyOjA4OjI0IC0wMDAwIn0sIn
ZtSWQiOiIifaCCAj8wggI7MIIBpKADAgECAhBnxW5Kh8dslEBA0E2mIBJ0MA0GCSqGSIb3DQEBBAUAMCsxKTAnBgNVBAMTIHRlc3RzdWJkb21h
aW4ubWV0YWRhdGEuYXp1cmUuY29tMB4XDTE4MTEyMDIxNTc1N1oXDTE4MTIyMDIxNTc1NlowKzEpMCcGA1UEAxMgdGVzdHN1YmRvbWFpbi5tZX
RhZGF0YS5henVyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAML/tBo86ENWPzmXZ0kPkX5dY5QZ150mA8lommszE71x2sCLonzv
4/UWk4H+jMMWRRwIea2CuQ5RhdWAHvKq6if4okKNt66fxm+YTVz9z0CTfCLmLT+nsdfOAsG1xZppEapC0Cd9vD6NCKyE8aYI1pliaeOnFjG0Wv
MY04uWz2MdAgMBAAGjYDBeMFwGA1UdAQRVMFOAENnYkHLa04Ut4Mpt7TkJFfyhLTArMSkwJwYDVQQDEyB0ZXN0c3ViZG9tYWluLm1ldGFkYXRh
LmF6dXJlLmNvbYIQZ8VuSofHbJRAQNBNpiASdDANBgkqhkiG9w0BAQQFAAOBgQCLSM6aX5Bs1KHCJp4VQtxZPzXF71rVKCocHy3N9PTJQ9Fpnd
+bYw2vSpQHg/AiG82WuDFpPReJvr7Pa938mZqW9HUOGjQKK2FYDTg6fXD8pkPdyghlX5boGWAMMrf7bFkup+lsT+n2tRw2wbNknO1tQ0wICtqy
2VqzWwLi45RBwTGB6DCB5QIBATA/MCsxKTAnBgNVBAMTIHRlc3RzdWJkb21haW4ubWV0YWRhdGEuYXp1cmUuY29tAhBnxW5Kh8dslEBA0E2mIB
J0MA0GCSqGSIb3DQEBCwUAMA0GCSqGSIb3DQEBAQUABIGAld1BM/yYIqqv8SDE4kjQo3Ul/IKAVR8ETKcve5BAdGSNkTUooUGVniTXeuvDj5Nk
mazOaKZp9fEtByqqPOyw/nlXaZgOO44HDGiPUJ90xVYmfeK6p9RpJBu6kiKhnnYTelUk5u75phe5ZbMZfBhuPhXmYAdjc7Nmw97nx8NnprQ="
}
El blob de firma es una versión con la firma pkcs7 del documento. Contiene el certificado usado para firmar
junto con detalles de la máquina virtual como vmld, nonce, subscriptionId y timeStamp para la creación y
expiración del documento y la información del plan sobre la imagen. La información del plan solo se rellena
para las imágenes de Azure Marketplace. El certificado se puede extraer de la respuesta y usarse para validar
que la respuesta es válida y viene de Azure.
Escenarios de ejemplo de uso

Seguimiento de una máquina virtual que se ejecuta en Azure
Como proveedor de servicios, es posible que necesite hacer seguimiento de la cantidad de máquinas virtuales que
ejecutan su software o que tenga agentes que deban hacer seguimiento de la unicidad de la máquina virtual. Para
poder obtener un identificador único para una máquina virtual, use el campo vmId del servicio de metadatos de
instancia.
Solicitud
curl -H Metadata:true "http://169.254.169.254/metadata/instance/compute/vmId?api-version=2017-08-

01&format=text"
Respuesta
5c08b38e-4d57-4c23-ac45-aca61037f084
Ubicación de los contenedores y el dominio de error/actualización basado en particiones de datos

Para ciertos escenarios, la ubicación de las distintas réplicas de datos es de máxima importancia. Por ejemplo, para
la ubicación de réplicas de HDFS o la ubicación de contenedores a través de un orquestador se debe saber en qué
platformFaultDomain y platformUpdateDomain se ejecuta la máquina virtual. También puede usar las zonas de
disponibilidad para las instancias para tomar estas decisiones. Puede consultar directamente estos datos a través
del servicio de metadatos de instancia.
Solicitud
curl -H Metadata:true "http://169.254.169.254/metadata/instance/compute/platformFaultDomain?api-version=2017-

08-01&format=text"
Respuesta
Obtención de más información sobre la VM durante el caso de soporte técnico

Como proveedor de servicios, es posible que reciba una llamada de soporte técnico en la que le gustaría tener
más información sobre la máquina virtual. Pedirle al cliente que comparta los metadatos del equipo puede
proporcionar información básica para que el profesional de soporte técnico conozca la variante de máquina
virtual en Azure.
Solicitud
curl -H Metadata:true "http://169.254.169.254/metadata/instance/compute?api-version=2017-08-01"
Respuesta
NOTE
legibilidad.
{
"compute": {
"location": "CentralUS",
"name": "IMDSCanary",
"offer": "RHEL",
"osType": "Linux",
"publisher": "RedHat",
"sku": "7.2",
"version": "7.2.20161026",
"vmId": "5c08b38e-4d57-4c23-ac45-aca61037f084",
"vmSize": "Standard_DS2"
}
}
Obtención del entorno de Azure donde se está ejecutando la máquina virtual

Azure tiene varias nubes soberanas, como Azure Government. En ocasiones, necesitará el entorno de Azure para
tomar algunas decisiones acerca del tiempo de ejecución. En el siguiente ejemplo se muestra cómo lograr este
comportamiento.
Solicitud
curl -H Metadata:true "http://169.254.169.254/metadata/instance/compute/azEnvironment?api-version=2018-10-

01&format=text"
Respuesta
AzurePublicCloud
Aquí se muestran las regiones y los valores del entorno de Azure.
REGIONS ENTORNO DE AZURE
Todas las regiones globales de Azure disponibles con carácter AzurePublicCloud

general
Azure Government AzureUSGovernmentCloud
Azure en China AzureChinaCloud
Azure Alemania AzureGermanCloud
Obtención de las etiquetas para la máquina virtual

Es posible que se hayan aplicado etiquetas a las máquinas virtuales de Azure para organizarlas de forma lógica en
una taxonomía. Las etiquetas asignadas a una máquina virtual se pueden recuperar mediante esta solicitud.
Solicitud
curl -H Metadata:true "http://169.254.169.254/metadata/instance/compute/tags?api-version=2018-10-

01&format=text"
Respuesta
Department:IT;Environment:Test;Role:WebRole
El campo tags es una cadena con las etiquetas delimitadas por puntos y coma. Esto puede ser un problema si se
usan puntos y coma en las propias etiquetas. Si se escribe un analizador para extraer las etiquetas mediante
programación, debe basarse en el campo tagsList , que es una matriz de JSON sin delimitadores y, por tanto,
más fácil de analizar.
Solicitud
curl -H Metadata:true "http://169.254.169.254/metadata/instance/compute/tagsList?api-version=2019-06-

04&format=JSON"
Respuesta
[
{
"name": "Department",
"value": "IT"
},
{
"name": "Environment",
"value": "Test"
},
{
"name": "Role",
"value": "WebRole"
}
]
Validación de que la máquina virtual se ejecuta en Azure

Los proveedores de Marketplace desean asegurarse de que su software tiene licencia para ejecutarse solo en
Azure. Si alguien copia el disco duro virtual en un entorno local, debería disponer de un capacidad para detectarlo.
Mediante una llamada al servicio de metadatos de instancia, los proveedores pueden obtener datos firmados que
garantizan la respuesta únicamente de Azure.
NOTE
Requiere jq para instalarse.
Solicitud
# Get the signature

curl --silent -H Metadata:True http://169.254.169.254/metadata/attested/document?api-version=2019-04-30 |
jq -r '.["signature"]' > signature
# Decode the signature
base64 -d signature > decodedsignature
#Get PKCS7 format
openssl pkcs7 -in decodedsignature -inform DER -out sign.pk7
# Get Public key out of pkc7
openssl pkcs7 -in decodedsignature -inform DER -print_certs -out signer.pem
#Get the intermediate certificate
wget -q -O intermediate.cer "$(openssl x509 -in signer.pem -text -noout | grep " CA Issuers -" | awk -FURI:
'{print $2}')"
openssl x509 -inform der -in intermediate.cer -out intermediate.pem
#Verify the contents
openssl smime -verify -in sign.pk7 -inform pem -noverify
Respuesta
Verification successful
{"nonce":"20181128-001617",
"plan":
{
"name":"",
"product":"",
"publisher":""
},
"timeStamp":
{
"createdOn":"11/28/18 00:16:17 -0000",
"expiresOn":"11/28/18 06:16:17 -0000"
},
"vmId":"d3e0e374-fda6-4649-bbc9-7f20dc379f34",
"subscriptionId": "xxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"
}
DATOS DESCRIPCIÓN
valor de seguridad El usuario especificó una cadena opcional con la solicitud. Si

no se proporcionó ningún nonce en la solicitud, se devuelve la
marca de tiempo UTC actual
plan Plan en una máquina virtual es una imagen de Azure

Marketplace que contiene el nombre, producto y editor
timestamp/createdOn La marca de tiempo en la que se creó el primer documento

firmado
timestamp/expiresOn La marca de tiempo en la que expira el documento firmado
vmId Identificador único para la máquina virtual.
subscriptionId Suscripción de Azure para la máquina virtual publicada con

fecha 2019-04-30
Comprobación de la firma
Una vez que obtenga la firma anterior, podrá comprobar que esta es de Microsoft. También podrá comprobar el
certificado intermedio y la cadena de certificados. Por último, puede comprobar que el identificador de suscripción
es correcto.
NOTE
El certificado para la nube pública y la nube soberana serán diferentes.
NUBE CERTIFICATE
Todas las regiones globales de Azure disponibles con carácter metadata.azure.com

general
Azure Government metadata.azure.us
Azure en China metadata.azure.cn

NUBE CERTIFICATE
Azure Alemania metadata.microsoftazure.de
# Verify the subject name for the main certificate

openssl x509 -noout -subject -in signer.pem
# Verify the issuer for the main certificate
openssl x509 -noout -issuer -in signer.pem
#Validate the subject name for intermediate certificate
openssl x509 -noout -subject -in intermediate.pem
# Verify the issuer for the intermediate certificate
openssl x509 -noout -issuer -in intermediate.pem
# Verify the certificate chain
openssl verify -verbose -CAfile /etc/ssl/certs/Baltimore_CyberTrust_Root.pem -untrusted intermediate.pem
signer.pem
En aquellos casos en los que el certificado intermedio no se puede descargar debido a restricciones de red
durante la validación, es posible anclarlo. No obstante, Azure sustituirá los certificados según el procedimiento
PKI estándar. Los certificados anclados deberán actualizarse cuando se produzca la sustitución. Cada vez que se
planee un cambio para actualizar el certificado intermedio, se actualizará el blog de Azure y se notificará a los
clientes de Azure. Encontrará los certificados intermedios aquí. Los certificados intermedios para cada una de las
regiones pueden ser diferentes.
Clústeres de conmutación por error de Windows Server
Para determinados escenarios, al consultar Instance Metadata Service con los clústeres de conmutación por error,
es necesario agregar una ruta a la tabla de enrutamiento.
1. Abra un símbolo del sistema con privilegios de administrador.
2. Ejecute el siguiente comando y anote la dirección de la interfaz de red de destino ( 0.0.0.0 ) en la tabla de
enrutamiento IPv4.
route print
NOTE
La siguiente salida de ejemplo de una máquina virtual de Windows Server con un clúster de conmutación por error
habilitado contiene solo la tabla de rutas IPv4 por motivos de simplicidad.
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.0.1.1 10.0.1.10 266
10.0.1.0 255.255.255.192 On-link 10.0.1.10 266
10.0.1.10 255.255.255.255 On-link 10.0.1.10 266
10.0.1.15 255.255.255.255 On-link 10.0.1.10 266
10.0.1.63 255.255.255.255 On-link 10.0.1.10 266
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
169.254.0.0 255.255.0.0 On-link 169.254.1.156 271
169.254.1.156 255.255.255.255 On-link 169.254.1.156 271
169.254.255.255 255.255.255.255 On-link 169.254.1.156 271
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 169.254.1.156 271
224.0.0.0 240.0.0.0 On-link 10.0.1.10 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 169.254.1.156 271
255.255.255.255 255.255.255.255 On-link 10.0.1.10 266
1. Ejecute el siguiente comando y use la dirección de la interfaz de red de destino ( 0.0.0.0 ) que es ( 10.0.1.10 )
en el ejemplo.
route add 169.254.169.254/32 10.0.1.10 metric 1 -p
Datos personalizados
Instance Metadata Service proporciona a la máquina virtual la capacidad de acceder a sus datos personalizados.
Los datos binarios deben tener menos de 64 KB y se proporcionan a la máquina virtual en formato codificado en
base64.
Los datos personalizados de Azure se pueden insertar en la máquina virtual a través de las API REST, los cmdlets
de PowerShell, la interfaz de la línea de comandos (CLI) de Azure o una plantilla de ARM.
Para obtener un ejemplo de la interfaz de la línea de comandos de Azure, vea Datos personalizados y Cloud-Init
en Microsoft Azure.
Para obtener un ejemplo de plantilla de ARM, vea Implementar una máquina Virtual con CustomData.
Los datos personalizados están disponibles para todos los procesos que se ejecutan en la máquina virtual. Se
recomienda que los clientes no inserten información secreta en los datos personalizados.
Actualmente, se garantiza que los datos personalizados estarán disponibles durante el arranque de una máquina
virtual. Si se realizan actualizaciones en la máquina virtual, como agregar discos o cambiar de tamaño la máquina
virtual, Instance Metadata Service no proporcionará datos personalizados. Actualmente está en curso la opción de
proporcionar datos personalizados de forma persistente a través de Instance Metadata Service.
Recuperar datos personalizados en la máquina virtual
Instance Metadata Service proporciona datos personalizados a la máquina virtual en formato codificado en
base64. En este ejemplo se descodifica la cadena codificada en base64.
NOTE
Los datos personalizados de este ejemplo se interpretan como una cadena ASCII que dice "Mis datos personalizados".
Solicitud
curl -H "Metadata:true" "http://169.254.169.254/metadata/instance/compute/customData?api-version=2019-02-
01&&format=text" | base64 --decode
Respuesta
My custom data.
Ejemplos de llamadas al servicio de metadatos mediante lenguajes diferentes dentro de la máquina virtual
IDIOMA EJEMPLO
Ruby https://github.com/Microsoft/azureimds/blob/master/IMDSSa
mple.rb
Go https://github.com/Microsoft/azureimds/blob/master/imdssa
mple.go
Python https://github.com/Microsoft/azureimds/blob/master/IMDSSa
mple.py
C++ https://github.com/Microsoft/azureimds/blob/master/IMDSSa
mple-windows.cpp
C# https://github.com/Microsoft/azureimds/blob/master/IMDSSa
mple.cs
JavaScript https://github.com/Microsoft/azureimds/blob/master/IMDSSa
mple.js
PowerShell https://github.com/Microsoft/azureimds/blob/master/IMDSSa
mple.ps1
Bash https://github.com/Microsoft/azureimds/blob/master/IMDSSa
mple.sh
Perl https://github.com/Microsoft/azureimds/blob/master/IMDSSa
mple.pl
Java https://github.com/Microsoft/azureimds/blob/master/imdssa
mple.java
Visual Basic https://github.com/Microsoft/azureimds/blob/master/IMDSSa

mple.vb
Puppet https://github.com/keirans/azuremetadata

1. Obtengo el error 400 Bad Request, Required metadata header not specified . ¿Qué significa?
El servicio de metadatos de instancia requiere que el encabezado Metadata: true se transmita en la
solicitud. Transmitir este encabezado en la llamada de REST permite tener acceso al servicio de
metadatos de instancia.
2. ¿Por qué no recibo información de proceso de mi máquina virtual?
Actualmente el servicio de metadatos de instancia solo admite instancias creadas con Azure Resource
Manager. En el futuro, es posible que se agregue compatibilidad para máquinas virtuales de servicio en
la nube.
3. Creé mi máquina virtual mediante Azure Resource Manager hace un tiempo. ¿Por qué no veo la
información de metadatos de proceso?
En el caso de las máquinas virtuales que se crearon después de septiembre de 2016, agregue una
etiqueta para empezar a ver los metadatos de proceso. En el caso de máquinas virtuales anteriores
(creadas antes de septiembre de 2016), agregue o quite extensiones o discos de datos a la máquina
virtual para actualizar los metadatos.
4. No veo todos los datos rellenados para la nueva versión
En el caso de las máquinas virtuales que se crearon después de septiembre de 2016, agregue una
etiqueta para empezar a ver los metadatos de proceso. En el caso de máquinas virtuales anteriores
(creadas antes de septiembre de 2016), agregue o quite extensiones o discos de datos a la máquina
virtual para actualizar los metadatos.
5. ¿Por qué recibo el error 500 Internal Server Error ?
Vuelva a intentar la solicitud en función del sistema de interrupción exponencial. Si el problema persiste,
póngase en contacto con el servicio de soporte técnico de Azure.
6. ¿Dónde puedo compartir preguntas o comentarios adicionales?
Envíe sus comentarios en https://feedback.azure.com.
7. ¿Esto funciona para la instancia del conjunto de escala de máquinas virtuales?
Sí, el servicio de metadatos está disponible para las instancias del conjunto de escala.
8. ¿Cómo puedo obtener soporte técnico para el servicio?
Para obtener soporte técnico para el servicio, cree un problema de compatibilidad en Azure Portal en la
máquina virtual en la que no obtiene respuesta de metadatos después de reintentos prolongados.
9. ¿Por qué se agotó el tiempo de espera de solicitud para mi llamada al servicio?
Se deben realizar llamadas de metadatos desde la dirección IP principal asignada a la tarjeta de red de
la máquina virtual; además, en caso de que haya cambiado las rutas, debe tener una ruta para la
dirección 169.254.0.0/16 desde su tarjeta de red.
10. He actualizado mis etiquetas en el conjunto de escalado de máquinas virtuales, pero no aparecen en las
instancias, a diferencia de las máquinas virtuales.
Actualmente, las etiquetas para ScaleSets solo se muestran a la máquina virtual durante un reinicio,
restablecimiento de imagen o cambio de disco en la instancia.
Pasos siguientes
Más información sobre los eventos programados.
Habilitación de la virtualización anidada en una
máquina virtual de Azure
La virtualización anidada es compatible con varias familias de máquinas virtuales de Azure. Esta funcionalidad
proporciona gran flexibilidad para admitir escenarios como entornos de desarrollo, pruebas, aprendizaje y
demostración.
En este artículo se analiza la habilitación de Hyper-V en una máquina virtual de Azure y la configuración de la
conectividad de Internet a esa máquina virtual invitada.
Creación de una máquina virtual de Azure compatible con el

anidamiento
Cree una nueva máquina virtual de Azure con Windows Server 2016. Como referencia rápida, todas las máquinas
virtuales v3 admiten la virtualización anidada. Para una lista completa de los tamaños de máquina virtual que
admiten anidamiento, visite el artículo Unidad de proceso de Azure (ACU ).
Recuerde elegir un tamaño de máquina virtual lo suficientemente grande para admitir las exigencias de una
invitada. En este ejemplo, se usa una máquina virtual con tamaño D3_v3.
Puede ver la disponibilidad regional de las máquinas virtuales de las series Dv3 o Ev3 aquí.
NOTE
Para instrucciones detalladas sobre cómo crear una máquina virtual nueva, consulte Creación y administración de máquinas
virtuales Windows con el módulo de Azure PowerShell
Conexión a una máquina virtual de Azure

Cree una conexión a Escritorio remoto en la máquina virtual.
1. Haga clic en el botón Conectar en las propiedades de la máquina virtual. Se crea y se descarga un archivo
de Protocolo de Escritorio remoto (archivo .rdp).
2. Para conectarse a la máquina virtual, abra el archivo RDP descargado. Cuando se le solicite, haga clic en
Conectar. En un equipo Mac, necesita un cliente RDP como este Cliente de Escritorio remoto de Mac App
Store.
3. Escriba el nombre de usuario y la contraseña que especificó al crear la máquina virtual y, a continuación,
haga clic en Aceptar.
4. Puede recibir una advertencia de certificado durante el proceso de inicio de sesión. Haga clic en Sí o
Conectar para continuar con la conexión.
Habilitación de la característica Hyper-V en la máquina virtual de Azure

Puede configurar estos ajustes de manera manual o usar el script de PowerShell que se proporciona para
automatizar la configuración.
Opción 1: Usar un script de PowerShell para configurar la virtualización anidada
Hay un script de PowerShell para habilitar la virtualización anidada en un host de Windows Server 2016
disponible en GitHub. El script comprueba los requisitos previos y, luego, configura la virtualización anidada en la
máquina virtual de Azure. Es necesario realizar un reinicio de la máquina virtual de Azure para completar la
configuración. Este script puede funcionar en otros entornos, pero no está garantizado. Consulte la entrada de blog
de Azure que incluye una demostración de vídeo en directo sobre la virtualización anidada en Azure.
https://aka.ms/AzureNVblog.
Opción 2: Configurar manualmente la virtualización anidada
1. En la máquina virtual de Azure, abra PowerShell como administrador.
2. Habilite la característica Hyper-V y las herramientas de administración.
Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart
WARNING
Con este comando se reinicia la máquina virtual de Azure. Perderá la conexión RDP durante el proceso de reinicio.
3. Una vez que la máquina virtual de Azure se reinicie, reconéctese a la VM con RDP.
Configuración de la conectividad de Internet de la máquina virtual

invitada
Cree un adaptador de red virtual nuevo para la máquina virtual invitada y configure una puerta de enlace NAT
para habilitar la conectividad de Internet.
Creación de un conmutador de red virtual NAT
2. Cree un conmutador interno.
New-VMSwitch -Name "InternalNAT" -SwitchType Internal
3. Consulte las propiedades del conmutador y anote el valor de ifIndex del adaptador nuevo.
Get-NetAdapter
NOTE
Anote el valor de "ifIndex" del conmutador virtual que acaba de crear.
4. Cree una dirección IP para la puerta de enlace NAT.

Para configurar la puerta de enlace, necesita información sobre la red:
IPAddress: la dirección IP de la puerta de enlace NAT especifica la dirección IPv4 o IPv6 que se va a usar
como la dirección de puerta de enlace predeterminada de la subred de la red virtual. El formato genérico es
a.b.c.1 (por ejemplo, "192.168.0.1"). Si bien no es necesario que la posición final sea .1, habitualmente sí lo es
(según la longitud de prefijo). Típicamente, debe usar un espacio de direcciones de red privadas RFC 1918.
PrefixLength: la longitud de prefijo de la subred define el tamaño de la subred local (máscara de subred). La
longitud de prefijo de la subred será un valor entero entre 0 y 32. 0 asignaría todo Internet, 32 solo
permitiría una dirección IP asignada. Los valores comunes van de 24 a 12 en función de cuántas direcciones
IP se deben adjuntar a NAT. Un valor de PrefixLength común es 24, que es una máscara de subred de
255.255.255.0.
InterfaceIndex: ifIndex es el índice de interfaz del conmutador virtual que se creó en el paso anterior.
New-NetIPAddress -IPAddress 192.168.0.1 -PrefixLength 24 -InterfaceIndex 13
Creación de la red NAT

Para configurar la puerta de enlace, deberá proporcionar información sobre la red y la puerta de enlace NAT:
Name: el nombre de la red NAT.
InternalIPInterfaceAddressPrefix: el prefijo de la subred NAT describe tanto el prefijo de la dirección IP de la
puerta de enlace NAT como la longitud de prefijo de la subred NAT anteriores. El formato genérico será
a.b.c.0/longitud de prefijo de la subred NAT.
En PowerShell, cree una red NAT nueva.
New-NetNat -Name "InternalNat" -InternalIPInterfaceAddressPrefix 192.168.0.0/24
Creación de la máquina virtual invitada

IMPORTANT
El agente invitado de Azure no se admite en máquinas virtuales anidadas y puede causar problemas en el host y en las
máquinas virtuales anidadas. No instale al agente de Azure en máquinas virtuales anidadas y no use una imagen para crear
las máquinas virtuales anidadas que ya tienen instalado el agente invitado de Azure.
1. Abra el Administrador de Hyper-V y cree una máquina virtual nueva. Configure la máquina virtual para
usar la red interna nueva que creó.
2. Instale un sistema operativo en la máquina virtual invitada.
NOTE
Necesita los medios de instalación de un sistema operativo para instalarlo en la máquina virtual. En este caso se usa
Windows 10 Enterprise.
Asignación de una dirección IP a la máquina virtual invitada

Puede asignar una dirección IP a la máquina virtual invitada ya sea estableciendo manualmente una dirección IP
estática en la máquina virtual invitada o configurando DHCP en la máquina virtual de Azure para asignar de
manera dinámica la dirección IP.
Opción 1: Configurar DHCP para asignar dinámicamente una dirección IP a la máquina virtual invitada
Siga estos pasos para configurar DHCP en la máquina virtual host para la asignación dinámica de direcciones.
Instalación del servidor DCHP en la máquina virtual de Azure
1. Abra el Administrador del servidor. En el panel, haga clic en Agregar roles y característica. Aparecerá el
Asistente para agregar roles y características.
2. En el asistente, haga clic en Siguiente hasta llegar a la página Roles del servidor.
3. Haga clic para activar la casilla Servidor DHCP, haga clic en Agregar características y en Siguiente hasta
completar el asistente.
4. Haga clic en Instalar.
Configuración de un nuevo ámbito de DHCP
1. Abra el Administrador DHCP.
2. En el panel de navegación, expanda el nombre del servidor, haga clic con el botón derecho IPv4 y, luego,
haga clic en Nuevo ámbito. Aparece el asistente para agregar un nuevo ámbito. Haga clic en Siguiente.
3. Escriba un nombre y una descripción para el ámbito y haga clic en Siguiente.
4. Defina un intervalo IP para el servidor DHCP (por ejemplo, de 192.168.0.100 a 192.168.0.200).
5. Haga clic en Siguiente hasta la página Puerta de enlace predeterminada. Escriba la dirección IP que creó
anteriormente (por ejemplo, 192.168.0.1) como la puerta de enlace predeterminada y después haga clic en
Agregar.
6. Haga clic en Siguiente hasta completar el asistente, deje todos los valores predeterminados y haga clic en
Finalizar.
Opción 2: Establecer manualmente una dirección IP estática en la máquina virtual invitada
Si no configuró DHCP para asignar de manera dinámica una dirección IP a la máquina virtual invitada, siga estos
pasos para establecer una dirección IP estática.
2. Haga clic con el botón derecho en la máquina virtual invitada y haga clic en Conectar.
3. Inicie sesión en la máquina virtual invitada.
4. En la máquina virtual invitada, abra el Centro de redes y recursos compartidos.
5. Configure el adaptador de red para una dirección dentro del intervalo de la red NAT que creó en la sección
anterior.
En este ejemplo usará una dirección dentro del intervalo 192.168.0.0/24.
Prueba de la conectividad en la máquina virtual invitada

En la máquina virtual invitada, abra el explorador y navegue a una página web.
Configuración de la conectividad de intranet de la máquina virtual

invitada
Para obtener instrucciones sobre cómo habilitar la conectividad transparente entre las máquinas virtuales invitadas
y las máquinas virtuales de Azure, consulte este documento.
Control de las notificaciones de mantenimiento
planeado de máquinas virtuales Windows
Azure realiza periódicamente actualizaciones para mejorar la confiabilidad, el rendimiento y la seguridad de la

infraestructura host de las máquinas virtuales. Las actualizaciones son cambios como la aplicación de revisiones en
el entorno de hospedaje o la actualización y la retirada de hardware. La mayoría de estas actualizaciones se realizan
sin afectar a las máquinas virtuales hospedadas. Sin embargo, hay casos en los que las actualizaciones tienen un
impacto:
Si el mantenimiento no requiere un reinicio, Azure usa la migración en contexto para pausar la máquina
virtual mientras se actualiza el host. Estas operaciones de mantenimiento sin reinicialización se aplican
dominio por dominio, si tienen errores, y el progreso se detiene si se recibe alguna señal de estado de
advertencia.
Si el mantenimiento requiere un reinicio, el usuario recibe un aviso de cuándo está programado el
mantenimiento. En estos casos, se le asigna también un período de tiempo, normalmente 35 días, donde
puede iniciar el mantenimiento a la hora que le resulte más cómodo.
El mantenimiento planeado que requiere un reinicio se programa en olas. Cada ola tiene un ámbito diferente
(regiones).
Una ola comienza con una notificación a los clientes. De forma predeterminada, la notificación se envía al
propietario de la suscripción y a los copropietarios. Con las alertas del registro de actividad de Azure es posible
agregar más destinatarios y opciones de mensajería, como el correo electrónico, los SMS y los webhooks, a las
notificaciones.
En el momento de la notificación, aparece una ventana de autoservicio. Durante esta ventana, que suele ser de
35 días, puede ver qué máquinas virtuales se incluyen en esta ola e iniciar de forma proactiva el mantenimiento
en función de las necesidades que dicte su programación.
Después de la ventana de autoservicio, comienza una ventana de mantenimiento programado. Mientras está
ventana está activa Azure programa el mantenimiento necesario y lo aplica a la máquina virtual.
El objetivo de tener dos ventanas es proporcionar tiempo suficiente para que pueda iniciar el mantenimiento y
reiniciar la máquina virtual sabiendo cuando iniciará Azure el mantenimiento automáticamente.
Puede usar Azure Portal, PowerShell, la API de REST y la CLI para consultar las ventanas de mantenimiento de las
máquinas virtuales e iniciar el mantenimiento de autoservicio.
¿Debe comenzar el mantenimiento durante la ventana de autoservicio?

Las directrices siguientes están pensadas para ayudarle a decidir si debe utilizar esta funcionalidad e iniciar el
mantenimiento a su ritmo.
NOTE
Es posible que el mantenimiento de autoservicio no esté disponible para todas las máquinas virtuales. Para determinar si su
máquina virtual se puede volver a implementar de forma proactiva, busque Iniciar ahora en el estado del mantenimiento. El
mantenimiento de autoservicio no está disponible para Cloud Services (rol de trabajo o web) y Service Fabric.
El mantenimiento de autoservicio no se recomienda para implementaciones que usen conjuntos de

disponibilidad, ya que éstas son configuraciones de alta disponibilidad, en las que en un momento dado solo
resulta afectado un dominio de actualización.
Deje que Azure desencadene el mantenimiento. Para el mantenimiento que requiera el reinicio, tenga en cuenta
que el mantenimiento se realizará dominio de actualización por dominio de actualización, que los dominios de
actualización no reciben necesariamente el mantenimiento de forma secuencial y que hay una pausa de 30
minutos entre los dominios de actualización.
Si una pérdida temporal de una parte de su capacidad (1/recuento de dominio de actualización) supone un
problema, se puede compensar fácilmente mediante la asignación de instancias adicionales durante el período
de mantenimiento.
Para el mantenimiento que no requiere el reinicio, las actualizaciones se aplican en el nivel de dominio de error.
No utilice el mantenimiento de autoservicio en los escenarios siguientes:
Si apaga las máquinas virtuales con frecuencia, ya sea manualmente, mediante DevTest Labs, con el apagado
automático o de forma programada, puede revertir el estado de mantenimiento y, por tanto, provocar mayor
tiempo de inactividad.
En las máquinas virtuales de corta duración que sepa que se van a eliminar antes del final del mantenimiento.
En el caso de las cargas de trabajo con un estado grande almacenadas en el disco local (efímero) en el que se
desea realizar el mantenimiento tras la actualización.
En los casos en los que se cambia el tamaño de una máquina virtual con frecuencia, ya que pudo revertir el
estado de mantenimiento.
Si ha realizado eventos programados que permiten una conmutación por error proactiva o un apagado
ordenado de la carga de trabajo, 15 minutos antes de que comience el apagado de mantenimiento
Use el mantenimiento de autoservicio si tiene planeado ejecutar la máquina virtual de forma ininterrumpida
durante la fase de mantenimiento programado y no se produce ninguna de las contraindicaciones anteriores.
Se recomienda usar el mantenimiento de autoservicio en los siguientes casos:
Es preciso comunicar una ventana de mantenimiento exacta a la dirección o al cliente final.
Es preciso completar el mantenimiento en una fecha determinada.
Es preciso controlar la secuencia de mantenimiento, por ejemplo, la aplicación de niveles múltiples para
garantizar la recuperación segura.
Se necesitan más de 30 minutos de recuperación de la máquina virtual entre dos dominios de actualización
(UD ). Para controlar el tiempo entre los dominios de actualización, no puede desencadenar el mantenimiento en
las máquinas virtuales en más de un dominio de actualización (UD ) a la vez.
Visualización de las máquinas virtuales programadas para

mantenimiento en el portal
Una vez que se programa una tanda de mantenimiento planeado, puede observar la lista de máquinas virtuales
que se ven afectadas por la siguiente tanda.
Puede usar Azure Portal y buscar máquinas virtuales con mantenimiento programado.
2. En el panel de navegación de la izquierda, haga clic en Máquinas virtuales.
3. En el panel Máquinas virtuales, haga clic en el botón Columnas para abrir la lista de columnas disponibles.
4. Seleccione y agregue las siguientes columnas:
Mantenimiento: muestra el estado de mantenimiento para la máquina virtual. Estos son los valores
posibles:
VALOR DESCRIPCIÓN
Empezar ahora La máquina virtual está en la ventana de mantenimiento

de autoservicio, lo que le permite iniciar el mantenimiento
usted mismo. Vea a continuación cómo iniciar el
mantenimiento en la máquina virtual.
Programado La máquina virtual está programada para el

mantenimiento sin opción de que inicie el mantenimiento.
Puede obtener información de la ventana de
mantenimiento mediante la selección de la ventana
Mantenimiento: Programado en esta vista o haciendo clic
en la máquina virtual.
Ya se actualizó La máquina virtual ya se actualizó y no se requiere

ninguna otra acción en este momento.
Inténtelo de nuevo más tarde Ha intentado iniciar el mantenimiento sin conseguirlo.

Podrá utilizar la opción de mantenimiento de autoservicio
más adelante.
Intentar ahora Puede volver a intentar un mantenimiento automático que

se intentó anteriormente sin éxito.
- La máquina virtual no forma parte de una oleada de

mantenimiento planeado.
Ventana Mantenimiento: Autoservicio: muestra la ventana de tiempo en la que puede iniciar el

mantenimiento usted mismo en las máquinas virtuales.
Ventana Mantenimiento: programado: muestra la ventana de tiempo en la que Azure reiniciará la
máquina virtual con el fin de realizar el mantenimiento.
Notificaciones y alertas en el portal

Azure comunica una programación para el mantenimiento planeado enviando un correo electrónico al grupo de
propietario y copropietarios de la suscripción. Puede agregar destinatarios y canales adicionales a esta
comunicación creando alertas de registro de actividad de Azure. Para más información, consulte Creación de
alertas del registro de actividad en notificaciones del servicio.
Asegúrese de establecer Tipo de evento como Mantenimiento planeado y Servicios como Virtual Machine
Scale Sets o Virtual Machines.
Inicio del mantenimiento en la máquina virtual desde el portal

Al examinar los detalles de la máquina virtual, podrá ver más detalles relacionados con el mantenimiento.
En la parte superior de la vista de detalles de la máquina virtual, se agregará una nueva cinta de opciones de
notificación si la máquina virtual se incluye en una tanda de mantenimiento planeado. Además, se agrega una
nueva opción para iniciar el mantenimiento siempre que sea posible.
Haga clic en la notificación de mantenimiento para ver la página de mantenimiento con más detalles en el
mantenimiento planeado. Desde allí podrá iniciar el mantenimiento en su máquina virtual.
Una vez que comience el mantenimiento, en pocos minutos comenzará en la máquina virtual y el estado de
mantenimiento se actualizará para reflejar el resultado.
Si se perdió la ventana de autoservicio, todavía podrá ver la ventana cuando Azure mantenga la máquina virtual.
Comprobación del estado de mantenimiento con PowerShell
También puede usar Azure Powershell para ver cuándo está programado el mantenimiento de las máquinas
virtuales. La información de mantenimiento planeado está disponible con el cmdlet Get-AzVM cuando se usa el
parámetro -status .
La información de mantenimiento se devuelve solo si hay mantenimiento planeado. Si no está programado ningún
mantenimiento que afecte a la máquina virtual, el cmdlet no devuelve ninguna información de mantenimiento.
Get-AzVM -ResourceGroupName rgName -Name vmName -Status
Las siguientes propiedades se devuelven en MaintenanceRedeployStatus:
VALOR DESCRIPCIÓN
IsCustomerInitiatedMaintenanceAllowed Indica si puede iniciar el mantenimiento en la máquina virtual

en este momento
PreMaintenanceWindowStartTime El comienzo de la ventana de autoservicio de mantenimiento

en la que puede iniciar el mantenimiento en la máquina virtual
PreMaintenanceWindowEndTime El final de la ventana de autoservicio de mantenimiento en la

que puede iniciar el mantenimiento en la máquina virtual
MaintenanceWindowStartTime El comienzo del mantenimiento programado en que Azure

inicia el mantenimiento de la máquina virtual
MaintenanceWindowEndTime El final de la ventana de mantenimiento programado en la que

Azure inicia el mantenimiento de la máquina virtual
LastOperationResultCode El resultado del último intento de iniciar el mantenimiento en

la máquina virtual
También puede obtener el estado de mantenimiento de todas las VM en un grupo de recursos mediante el uso de
Get-AzVM sin especificar una VM.
Get-AzVM -ResourceGroupName rgName -Status
La siguiente función de PowerShell toma el identificador de la suscripción e imprime una lista de máquinas
virtuales que están programadas para su mantenimiento.
function MaintenanceIterator
{
Select-AzSubscription -SubscriptionId $args[0]
$rgList= Get-AzResourceGroup
for ($rgIdx=0; $rgIdx -lt $rgList.Length ; $rgIdx++)

{
$rg = $rgList[$rgIdx]
$vmList = Get-AzVM -ResourceGroupName $rg.ResourceGroupName
for ($vmIdx=0; $vmIdx -lt $vmList.Length ; $vmIdx++)
{
$vm = $vmList[$vmIdx]
$vmDetails = Get-AzVM -ResourceGroupName $rg.ResourceGroupName -Name $vm.Name -Status
if ($vmDetails.MaintenanceRedeployStatus )
{
Write-Output "VM: $($vmDetails.Name) IsCustomerInitiatedMaintenanceAllowed:
$($vmDetails.MaintenanceRedeployStatus.IsCustomerInitiatedMaintenanceAllowed)
$($vmDetails.MaintenanceRedeployStatus.LastOperationMessage)"
}
}
}
}
Inicio del mantenimiento en la máquina virtual mediante PowerShell

Con la información de la función de la sección anterior, lo siguiente inicia el mantenimiento en una máquina virtual
si IsCustomerInitiatedMaintenanceAllowed está establecido en true.
Restart-AzVM -PerformMaintenance -name $vm.Name -ResourceGroupName $rg.ResourceGroupName
Implementaciones clásicas
Si todavía tiene máquinas virtuales heredadas que se han implementado según el modelo de implementación
clásico, puede usar PowerShell para consultar las máquinas virtuales e iniciar el mantenimiento.
Para obtener el estado de mantenimiento de una máquina virtual, escriba lo siguiente:
Get-AzureVM -ServiceName <Service name> -Name <VM name>
Para iniciar el mantenimiento en una máquina virtual clásica, escriba lo siguiente:
Restart-AzureVM -InitiateMaintenance -ServiceName <service name> -Name <VM name>

P: ¿Por qué hay que reiniciar las máquinas virtuales ahora?
R: Aunque la mayoría de las actualizaciones de la plataforma de Azure no afectan a la disponibilidad de la máquina
virtual, hay casos en los que es imposible evitar reiniciar las máquinas virtuales hospedadas en Azure. Hemos
acumulado varios cambios que requieren el reinicio de nuestros servidores, lo que conllevará el reinicio de las
P: Si sigo las recomendaciones para lograr una alta disponibilidad mediante un conjunto de
disponibilidad, ¿estoy seguro?
R: Las máquinas virtuales implementadas en un conjunto de disponibilidad o en conjuntos de escalado de
máquinas virtuales tienen la noción de dominios de actualización (UD ). Al realizar mantenimiento, Azure respeta la
restricción de UD, por lo que no reiniciará máquinas virtuales de diferentes UD (del mismo conjunto de
disponibilidad). Azure también espera al menos 30 minutos antes de pasar al siguiente grupo de máquinas
virtuales.
Para más información sobre la alta disponibilidad, consulte Availability for virtual machines in Azure
(Disponibilidad para máquinas virtuales en Azure).
P: ¿Cómo recibo notificaciones acerca del mantenimiento planeado?
R: Una oleada de mantenimiento planeado se inicia mediante el establecimiento de una programación en una o
varias regiones de Azure. Poco después, se envía una notificación por correo electrónico a los propietarios de las
suscripciones (un correo electrónico por suscripción). Mediante Alertas de registro de actividad se pueden
configurar más canales y destinatarios de esta notificación. En caso de que implemente una máquina virtual en una
región en la que ya se ha programado un mantenimiento planeado, no recibirá la notificación, sino que tendrá que
comprobar el estado de mantenimiento de la máquina virtual.
P: No veo ninguna indicación de mantenimiento planeado en el portal, Powershell o la CLI. ¿Qué está
pasando?
R: La información relacionada con el mantenimiento planeado está disponible durante una tanda de
mantenimiento planeado solo para las máquinas virtuales que van a verse afectadas por el mismo. En otras
palabras, si no ve datos, es posible que la oleada de mantenimiento se haya completado (o que no haya empezado)
o que la máquina virtual ya esté alojada en un servidor actualizado.
P: ¿Existe alguna una manera de saber exactamente cuándo se verá afectada mi máquina virtual?
R: Al establecer la programación, definimos una ventana de tiempo de varios días. Sin embargo, se desconoce la
secuencia exacta de los servidores (y las máquinas virtuales) en esta ventana. Los clientes que deseen conocer el
tiempo exacto para sus máquinas virtuales pueden usar eventos programados y realizar consultas desde la propia
máquina virtual y recibir una notificación 15 minutos antes de que una máquina virtual se reinicie.
P: ¿Cuánto tiempo tardará en reiniciar mi máquina virtual?
R: En función del tamaño de la máquina virtual, el reinicio podría tardar varios minutos durante la ventana de
mantenimiento de autoservicio. En los reinicios ejecutados por Azure en la ventana de mantenimiento
programada, el reinicio suele tardar unos 25 minutos. Tenga en cuenta que, si usa Cloud Services (roles de trabajo
o web), Virtual Machine Scale Sets o conjuntos de disponibilidad, se le proporcionarán treinta minutos entre cada
grupo de máquinas virtuales (UD ) durante la ventana de mantenimiento programado.
P: ¿Cuál es la experiencia en el caso de los conjuntos de escalado de máquinas virtuales?
R: El mantenimiento planeado está ahora disponible para los conjuntos de escalado de máquinas virtuales. Para
obtener instrucciones sobre cómo iniciar el mantenimiento de autoservicio, consulte el documento mantenimiento
planeado de VMSS.
P: ¿Cómo es la experiencia en el caso de Cloud Services (roles de trabajo o web) y Service Fabric?
R: Aunque estas plataformas resultan afectadas por el mantenimiento planeado, se considera que los clientes que
las usan están seguros, ya que solo resultarán afectadas en cualquier momento las máquinas virtuales de un
dominio de actualización (UD ) individual. El mantenimiento de autoservicio no está disponible para Cloud Services
(rol de trabajo o web) y Service Fabric.
P: No veo información de mantenimiento en mis máquinas virtuales. ¿A qué se debe?
R: Hay varios motivos por los que no ve información de mantenimiento en sus máquinas virtuales:
1. Utiliza una suscripción marcada como interna de Microsoft.
2. Las máquinas virtuales no están programadas para su mantenimiento. Es posible que la tanda de
mantenimiento haya finalizado, se haya cancelado o se haya modificado para que las máquinas virtuales dejen
de verse afectadas por ella.
3. La columna Mantenimiento no se ha agregado a la vista de la lista de máquinas virtuales. Aunque hemos
agregado esta columna a la vista predeterminada, los clientes que se han configurado para ver las columnas no
predeterminadas deben agregar manualmente la columna de mantenimiento a la vista de lista de máquinas
virtuales.
P: Está programado que se realice un segundo mantenimiento programado de mi máquina virtual. ¿Por
qué?
R: Hay varios casos en los que verá que el mantenimiento de su máquina virtual está programado después de que
se haya completado el ciclo de mantenimiento y reimplementación:
1. Hemos cancelado la oleada de mantenimiento y la hemos reiniciado con otra carga útil. Es posible que hayamos
detectado una carga útil con errores y que necesitemos implementar una carga adicional.
2. El servicio de una máquina virtual se ha reparado en otro nodo debido a un error de hardware
3. Ha seleccionado detener (desasignar) y reiniciar la máquina virtual
4. El apagado automático se ha activado en la máquina virtual
Pasos siguientes
Obtenga información acerca de cómo puede registrarse para eventos de mantenimiento desde la máquina virtual
con Eventos programados.
Azure Metadata Service: Scheduled Events para
máquinas virtuales Windows
Eventos programados es un servicio de Azure Metadata Service que proporciona el tiempo de aplicación para
prepararse para el mantenimiento de la máquina virtual. Proporciona información sobre los eventos de
mantenimiento próximos (por ejemplo, un reinicio) para que la aplicación se pueda preparar y así limitar las
interrupciones. Está disponible para todos los tipos de máquina virtual de Azure, incluido IaaS y PaaS, tanto en
Windows como en Linux.
Para más información acerca de Scheduled Events en Linux, consulte Scheduled Events para máquinas virtuales
Linux.
NOTE
Scheduled Events está disponible con carácter general en todas las regiones de Azure. Consulte el apartado sobre la
disponibilidad por región y versión para obtener información sobre la versión más reciente.
¿Por qué Scheduled Events?

Muchas aplicaciones pueden beneficiarse del tiempo de preparación para el mantenimiento de las máquinas
virtuales. Este tiempo se puede usar para realizar tareas específicas de la aplicación con el fin de mejorar la
disponibilidad, la confiabilidad y la capacidad de servicio, lo que incluye:
Punto de control y restauración
Purga de la conexión
Conmutación por error de la réplica principal
Eliminación del grupo de equilibradores de carga
Registros de eventos
Apagado correcto
Con Eventos programados, la aplicación puede detectar cuándo se producirá el mantenimiento y desencadenar
tareas para limitar su impacto. Habilitar eventos programados ofrece a la máquina virtual una cantidad mínima
de tiempo antes de que se lleve a cabo la actividad de mantenimiento. Consulte la sección de programación de
eventos a continuación para obtener más información.
Eventos programados proporciona eventos en los casos de uso siguientes:
Mantenimiento iniciado por la plataforma (por ejemplo, reinicio de máquina virtual, migración en vivo o
actualizaciones con conservación de memoria para el host)
Hardware degradado
Mantenimiento iniciado por el usuario (por ejemplo, el usuario reinicia o vuelve a implementar una máquina
virtual)
Expulsión de la máquina virtual de baja prioridad en conjuntos de escalado
Conceptos básicos
Azure Metadata Service expone información sobre la ejecución de máquinas virtuales mediante un punto de
conexión de REST accesible desde la propia máquina virtual. La información se encuentra disponible a través de
una dirección IP no enrutable, de modo que no se expone fuera de la máquina virtual.
Detección de punto de conexión
En el caso de las máquinas virtuales con red virtual habilitada, el servicio de metadatos está disponible desde
una dirección IP no enrutable estática, 169.254.169.254 . El punto de conexión completo de la versión más
reciente de Scheduled Events es:
http://169.254.169.254/metadata/scheduledevents?api-version=2017-11-01
Si la máquina virtual no se crea dentro de una red virtual (lo habitual para servicios en la nube y VM clásicas),
se necesita una lógica adicional para detectar la dirección IP que se va a usar. Consulte esta muestra para
obtener información sobre cómo descubrir el punto de conexión de host.
Disponibilidad por región y versión
El servicio Eventos programados tiene versiones. Las versiones son obligatorias y la versión actual es la
2017-11-01 .
VERSIÓN TIPO DE VERSIÓN REGIONS NOTAS DE LA VERSIÓN
01-11-2017 Disponibilidad general All Se agregó compatibilidad

para la expulsión de la
máquina virtual de baja
prioridad EventType
'Preempt'
2017-08-01 Disponibilidad general All Se quitó el guion bajo

antepuesto de los nombres
de recursos en las máquinas
virtuales de IaaS
Se aplicó el requisito de
encabezado de metadatos
para todas las solicitudes
2017-03-01 Vista previa All Versión inicial.
NOTE
Las versiones preliminares de eventos programados compatibles {más reciente} como la versión de api. Este formato ya no
es compatible y dejará de utilizarse en el futuro.
Habilitación y deshabilitación de Scheduled Events

Scheduled Events se habilita para un servicio la primera vez que se realiza una solicitud de eventos. Debe
esperar hasta dos minutos de demora en la respuesta en la primera llamada. Debería consultar el punto de
conexión periódicamente para detectar los próximos eventos de mantenimiento, así como el estado de las
actividades de mantenimiento que se van a realizar.
Scheduled Events se deshabilita para el servicio si no se realiza una solicitud durante 24 horas.
Mantenimiento iniciado por el usuario
El mantenimiento de máquina virtual iniciado por el usuario a través de Azure Portal, API, CLI o PowerShell da
lugar a un evento programado. Esto permite probar la lógica de preparación de mantenimiento en su aplicación.
Asimismo, permite a su aplicación prepararse para el mantenimiento iniciado por el usuario.
Si se reinicia una máquina virtual, se programa un evento con el tipo Reboot . Si vuelve a implementar una
máquina virtual, se programa un evento con el tipo Redeploy .
Uso de la API
encabezados
Al realizar consultas a Metadata Service, debe proporcionar el encabezado Metadata:true para asegurarse de
que la solicitud no se haya redirigido de manera involuntaria. El encabezado Metadata:true es necesario para
todas las solicitudes de eventos programados. Un error al incluir el encabezado en la solicitud generará una
respuesta del tipo Solicitud incorrecta del servicio de metadatos.
Consulta de eventos
Puede consultar los eventos programados; para ello, simplemente haga la siguiente llamada:
PowerShell
curl http://169.254.169.254/metadata/scheduledevents?api-version=2017-11-01 -H @{"Metadata"="true"}
Una respuesta contiene una matriz de eventos programados. Una matriz vacía significa que actualmente no hay
eventos programados. En caso de que haya eventos programados, la respuesta contiene una matriz de eventos:
{
"DocumentIncarnation": {IncarnationID},
"Events": [
{
"EventId": {eventID},
"EventType": "Reboot" | "Redeploy" | "Freeze" | "Preempt",
"ResourceType": "VirtualMachine",
"Resources": [{resourceName}],
"EventStatus": "Scheduled" | "Started",
"NotBefore": {timeInUTC},
}
]
}
DocumentIncarnation es una etiqueta de entidad y proporciona una manera fácil de inspeccionar si la carga de
eventos ha cambiado desde la última consulta.
Propiedades de evento
PROPIEDAD DESCRIPCIÓN
EventId Es un identificador único global del evento.
Ejemplo:
602d9444-d2cd-49c7-8624-8643e7171297
PROPIEDAD DESCRIPCIÓN
EventType Es el impacto causado por el evento.
Valores:
Freeze : la máquina virtual está programada para
pausarse durante unos segundos. Puede que se
suspenda la conectividad de la CPU y la red, pero no
afecta a la memoria ni a los archivos abiertos.
Reboot : la máquina virtual está programada para
reiniciarse (se borrará la memoria no persistente).
Redeploy : la máquina virtual está programada para
moverse a otro nodo (los discos efímeros se pierden).
Preempt : Se está eliminando la máquina virtual de
baja prioridad (se pierden los discos efímeros).
ResourceType Es el tipo de recurso al que afecta este evento.
Valores:
VirtualMachine
Recursos Es la lista de recursos a la que afecta este evento. Se

garantiza que contenga máquinas de un dominio de
actualización como máximo, pero puede no contener todas
las máquinas en el dominio.
Ejemplo:
["FrontEnd_IN_0", "BackEnd_IN_0"]
Estado de evento Es el estado de este evento.
Valores:
Scheduled : este evento está programado para
iniciarse después de la hora especificada en la
propiedad NotBefore .
Started : este evento se ha iniciado.
Nunca se proporcionan Completed ni ningún estado

similar; el evento ya no se devolverá cuando finalice.
NotBefore Hora a partir de la que puede iniciarse este evento.
Ejemplo:
Lunes, 19 de septiembre de 2016, 18:29:47 GMT
Programación de eventos
Cada evento se programa una cantidad mínima de tiempo en el futuro en función del tipo de evento. Este
tiempo se refleja en la propiedad NotBefore de un evento.
EVENTTYPE MINIMUM NOTICE
Freeze 15 minutos
Reboot 15 minutos
EVENTTYPE MINIMUM NOTICE
Volver a implementar 10 minutos
Preempt 30 segundos
Ámbito actual
Los eventos programados se entregan a:
Máquinas virtuales independientes
Todas las máquinas virtuales de un servicio en la nube.
Todas las máquinas virtuales de un conjunto de disponibilidad.
Todas las máquinas virtuales de un grupo de selección de ubicación de conjunto de escalado.
Por ello, debería revisar el campo Resources del evento para identificar cuáles son las máquinas virtuales que se
verán afectadas.
Inicio de un evento
Una vez que se haya enterado de un evento próximo y que haya completado la lógica para un apagado estable,
puede aprobar el evento pendiente mediante una llamada de POST a Metadata Service con EventId . Esta indica
a Azure que puede acortar el tiempo de notificación mínimo (cuando sea posible).
A continuación se muestra el JSON esperado en el cuerpo de la solicitud POST . La solicitud debe contener una
lista de StartRequests . Cada StartRequest contiene el elemento EventId para el evento que desea acelerar:
{
"StartRequests" : [
{
"EventId": {EventId}
}
]
}
PowerShell
curl -H @{"Metadata"="true"} -Method POST -Body '{"StartRequests": [{"EventId": "f020ba2e-3bc0-4c40-a10b-

86575a9eabd5"}]}' -Uri http://169.254.169.254/metadata/scheduledevents?api-version=2017-11-01
NOTE
Reconocer un evento permite a este continuar para todos sus elementos Resources , no solo para la máquina virtual que
lo reconoce. Por tanto, puede optar por elegir un líder para que coordine el reconocimiento. Este puede ser tan sencillo
como la propia máquina del campo Resources .
Ejemplo de PowerShell
En el siguiente ejemplo se realiza una consulta a Metadata Service para eventos programados y se aprueban
todos los eventos pendientes.
# How to get scheduled events
function Get-ScheduledEvents($uri)
{
$scheduledEvents = Invoke-RestMethod -Headers @{"Metadata"="true"} -URI $uri -Method get
$json = ConvertTo-Json $scheduledEvents
Write-Host "Received following events: `n" $json
return $scheduledEvents
}
# How to approve a scheduled event

function Approve-ScheduledEvent($eventId, $uri)
{
# Create the Scheduled Events Approval Document
$startRequests = [array]@{"EventId" = $eventId}
$scheduledEventsApproval = @{"StartRequests" = $startRequests}
# Convert to JSON string

$approvalString = ConvertTo-Json $scheduledEventsApproval
Write-Host "Approving with the following: `n" $approvalString
# Post approval string to scheduled events endpoint

Invoke-RestMethod -Uri $uri -Headers @{"Metadata"="true"} -Method POST -Body $approvalString
}
function Handle-ScheduledEvents($scheduledEvents)
{
# Add logic for handling events here
}
######### Sample Scheduled Events Interaction #########
# Set up the scheduled events URI for a VNET-enabled VM

$localHostIP = "169.254.169.254"
$scheduledEventURI = 'http://{0}/metadata/scheduledevents?api-version=2017-11-01' -f $localHostIP
# Get events
$scheduledEvents = Get-ScheduledEvents $scheduledEventURI
# Handle events however is best for your service

Handle-ScheduledEvents $scheduledEvents
# Approve events when ready (optional)

foreach($event in $scheduledEvents.Events)
{
Write-Host "Current Event: `n" $event
$entry = Read-Host "`nApprove event? Y/N"
if($entry -eq "Y" -or $entry -eq "y")
{
Approve-ScheduledEvent $event.EventId $scheduledEventURI
}
}
Pasos siguientes
Vea una demostración de Scheduled Events en Azure el viernes.
Repase los ejemplos de código de Scheduled Events en Azure Instance Metadata Scheduled Events GitHub
repository (Repositorio GitHub de Scheduled Events de Azure Instance Metadata).
En Instance Metadata Service (Servicio Instance Metadata), puede obtener más información sobre las API
disponibles.
Obtenga información sobre cómo realizar el mantenimiento planeado para máquinas virtuales Windows en
Azure.
Supervisión de Scheduled Events
Las actualizaciones se aplican a diferentes partes de Azure cada día, para que los servicios que se ejecutan en ellas
sean seguros y estén actualizados. Además de las actualizaciones planeadas, también se pueden producir eventos
no planeados. Por ejemplo, si se detecta algún error o degradación del hardware, es posible que los servicios de
Azure necesiten realizar un mantenimiento no planeado. Con la migración en vivo, la conservación de
actualizaciones en la memoria y al mantener de forma general un control estricto acerca del impacto de las
actualizaciones, en la mayoría de los casos estos eventos son casi transparentes para los clientes y no tienen ningún
impacto o, como máximo, causan unos segundos de inmovilización en la máquina virtual. Sin embargo, para
algunas aplicaciones, incluso unos pocos segundos de inmovilización en las máquinas virtuales podría tener un
impacto. Es importante conocer por adelantado el próximo mantenimiento de Azure para garantizar la mejor
experiencia para esas aplicaciones. El servicio Scheduled Events proporciona una interfaz de programación para
recibir notificaciones sobre el próximo mantenimiento y le permite administrar correctamente el mantenimiento.
En este artículo, le mostraremos cómo puede usar los eventos programados para recibir notificaciones sobre los
eventos de mantenimiento que podrían afectar a las máquinas virtuales y crear una automatización básica que
pueda ayudar con la supervisión y el análisis.
Enrutamiento de eventos programados a Log Analytics

Scheduled Events está disponible como parte de Azure Instance Metadata Service, que está disponible en todas las
máquinas virtuales de Azure. Los clientes pueden escribir automatizaciones para consultar el punto de conexión de
sus máquinas virtuales para buscar notificaciones de mantenimiento programado y realizar mitigaciones, tales
como guardar el estado y sacar la máquina virtual de la rotación. Se recomienda crear la automatización para
registrar Scheduled Events de modo que pueda tener un registro de auditoría de los eventos de mantenimiento de
Azure.
En este artículo, le guiaremos a través de la captura de mantenimiento de Scheduled Events en Log Analytics.
Después, se desencadenarán algunas acciones de notificación básicas, como enviar un correo electrónico al equipo
y obtener una vista histórica de todos los eventos que han afectado a las máquinas virtuales. Para la agregación y
automatización de eventos usaremos Log Analytics, pero puede usarse cualquier solución de supervisión para
recopilar estos registros y desencadenar la automatización.
Requisitos previos
En este ejemplo, tendrá que crear una máquina virtual Windows en un conjunto de disponibilidad. Scheduled
Events proporciona notificaciones sobre los cambios que pueden afectar a cualquiera de las máquinas virtuales del
conjunto de disponibilidad, el servicio en la nube, el conjunto de escalado de máquinas virtuales o a las máquinas
virtuales independientes. Se va a ejecutar un servicio que sondea los eventos programados en una de las máquinas
virtuales, la cual actuará como recopilador para obtener los eventos de todas las demás máquinas virtuales del
conjunto de disponibilidad.
No elimine el grupo de recursos del grupo al final del tutorial.
También necesitará crear un área de trabajo de Log Analytics que se usará para agregar información de las
máquinas virtuales del conjunto de disponibilidad.
Configuración del entorno

Ahora debería tener dos máquinas virtuales iniciales en un conjunto de disponibilidad. Ahora debemos crear una
tercera máquina virtual, denominada myCollectorVM, en el mismo conjunto de disponibilidad.
New-AzVm `
-Name "myCollectorVM" `
-OpenPorts 3389 `
-PublicIpAddressName "myPublicIpAddress3" `
-Credential $cred
Descargue el archivo .ZIP de instalación del proyecto de GitHub.

Conéctese a myCollectorVM, copie el archivo .ZIP en la máquina virtual y extraiga todos los archivos. En la
máquina virtual, abra un símbolo del sistema de PowerShell. Mueva el símbolo del sistema a la carpeta que
contiene SchService.ps1 , por ejemplo:
PS C:\Users\azureuser\AzureScheduledEventsService-master\AzureScheduledEventsService-master\Powershell> , y
configure el servicio.
.\SchService.ps1 -Setup
Inicie el servicio.
.\SchService.ps1 -Start
Ahora, el servicio comenzará a realizar un sondeo cada 10 segundos para cualquier evento programado y aprobará
los eventos para acelerar su mantenimiento. Scheduled Events captura los eventos Inmovilizar, Reiniciar,
Reimplementar y Reemplazar. Tenga en cuenta que puede extender el script para desencadenar algunas
mitigaciones antes de aprobar el evento.
Valide el estado del servicio y asegúrese de que se está ejecutando.
.\SchService.ps1 -status
Esto debería devolver el valor Running .

Ahora, el servicio comenzará a realizar un sondeo cada 10 segundos para cualquier evento programado y aprobará
los eventos para acelerar su mantenimiento. Scheduled Events captura los eventos Inmovilizar, Reiniciar,
Reimplementar y Reemplazar. Puede extender el script para desencadenar algunas mitigaciones antes de aprobar
el evento.
Cuando el servicio de eventos de programación captura cualquiera de los eventos anteriores, se registra en los
valores de Event Status, Event Type, Resources (nombres de máquina virtual) y NotBefore (período mínimo de
aviso) del registro de eventos de la aplicación. Puede buscar los eventos con el id. 1234 en el registro de eventos de
la aplicación.
Una vez que el servicio se ha configurado e iniciado, registrará los eventos en los registros de aplicación de
Windows. Para comprobar que funciona, reinicie una de las máquinas virtuales en el conjunto de disponibilidad y
debería ver que se está registrando un evento en el Visor de eventos en Registros de Windows > Registro de
aplicación, donde se muestra que la máquina virtual se reinició.
Cuando el servicio Scheduled Events captura eventos, se registran en el registro de eventos de la aplicación con los
valores de Event Status, Event Type, Resources (nombre de máquina virtual) y NotBefore (período mínimo de
aviso). Puede buscar los eventos con el id. 1234 en el registro de eventos de la aplicación.
NOTE
En este ejemplo, las máquinas virtuales se encontraban en un conjunto de disponibilidad, por lo que pudimos designar una
única máquina virtual como recopilador para escuchar y enrutar los eventos programados a nuestro espacio de trabajo de
Log Analytics. Si tiene máquinas virtuales independientes, puede ejecutar el servicio en todas las máquinas virtuales y, a
continuación, conectarlas individualmente a su área de trabajo de Log Analytics.
Para esta configuración, elegimos Windows, pero puede diseñar una solución similar en Linux.
En cualquier momento puede detener o quitar el servicio Scheduled Event los modificadores –stop y –remove .
Conexión a un área de trabajo

Ahora queremos conectar un área de trabajo de Log Analytics a la máquina virtual del recopilador. El área de
trabajo de Log Analytics actúa como repositorio y la recopilación de registros de eventos se configurará para
capturar los registros de aplicaciones de la máquina virtual del recopilador.
Para enrutar Scheduled Events al registro de eventos (que el servicio guardará como registro de aplicaciones),
deberá conectar la máquina virtual a su área de trabajo de Log Analytics.
1. Abra la página del área de trabajo que creó.
2. En Conectarse a un origen de datos seleccione Máquinas virtuales de Azure (VM ) .
3. Busque y seleccione myCollectorVM.

4. En la página nueva de myCollectorVM, seleccione Conectar.
Se instalará Microsoft Monitoring Agent en la máquina virtual. La máquina virtual tardará unos minutos en
conectarse al área de trabajo e instalar la extensión.
Configuración del área de trabajo

1. Abra la página del área de trabajo y seleccione Configuración avanzada.
2. Seleccione Datos en el menú de la izquierda y, a continuación, Registros de eventos de Windows.
3. En Recopilar eventos de los registros de eventos siguientes, empiece a escribir aplicación y, a
continuación, seleccione Aplicación en la lista.
4. Deje seleccionada la opción ERROR, ADVERTENCIA e INFORMACIÓN y, a continuación, seleccione

Guardar para guardar la configuración.
NOTE
Habrá cierto retraso y el registro puede tardar hasta 10 minutos en estar disponible.
Creación de una regla de alerta con Azure Monitor
Una vez que los eventos se insertan en Log Analytics, puede ejecutar la consulta siguiente para buscar los eventos
de programación.
1. En la parte superior de la página, seleccione Registros y pegue lo siguiente en el cuadro de texto:
Event
| where EventLog == "Application" and Source contains "AzureScheduledEvents" and RenderedDescription
contains "Scheduled" and RenderedDescription contains "EventStatus"
| project TimeGenerated, RenderedDescription
| extend ReqJson= parse_json(RenderedDescription)
| extend EventId = ReqJson["EventId"]
,EventStatus = ReqJson["EventStatus"]
,EventType = ReqJson["EventType"]
,NotBefore = ReqJson["NotBefore"]
,ResourceType = ReqJson["ResourceType"]
,Resources = ReqJson["Resources"]
| project-away RenderedDescription,ReqJson
2. Seleccione Guardar y, a continuación, escriba logQuery para el nombre, deje Consulta como tipo, escriba
VMLogs como Categoría y después seleccione Guardar.
3. Seleccione Nueva regla de alertas.

4. En la página Crear regla, deje collectorworkspace como Recurso.
5. En Condición, seleccione la entrada Whenever the customer log search (Cada vez que la búsqueda de
registros del cliente sea). Se abrirá la página Configurar lógica de señal.
6. En Valor del umbral, escriba 0 y seleccione Listo.
7. En Acciones, seleccione Crear grupo de acciones. Se abrirá la página Agregar grupo de acciones.
8. En Nombre del grupo de acciones, escriba myActionGroup.
9. En Nombre corto, escriba myActionGroup.
10. En Grupo de recursos, seleccione myResourceGroupAvailability.
11. En Acciones, en NOMBRE DE ACCIÓN escriba Correo electrónico y, a continuación, seleccione
Email/SMS/Push/Voice (Correo electrónico/SMS/Push/Voz). Se abre la página
Email/SMS/Push/Voice (Correo electrónico/SMS/Push/Voz).
12. Seleccione Correo electrónico, escriba su dirección de correo electrónico y después haga clic en Aceptar.
13. En la página Agregar grupo de acciones, seleccione Aceptar.
14. En la página Crear regla, en DETALLES DE ALERTA, escriba myAlert como Nombre de la regla de
alertas y escriba Regla de alertas de correo electrónico en la Descripción.
15. Cuando finalice, seleccione Crear regla de alertas.
16. Reinicie una de las máquinas virtuales del conjunto de disponibilidad. En unos minutos, recibirá un mensaje
de correo electrónico que indica que se desencadenó la alerta.
Para administrar las reglas de alertas, vaya al grupo de recursos, seleccione Alertas en el menú de la izquierda y, a
continuación, seleccione Administrar las reglas de alertas en la parte superior de la página.
Pasos siguientes
Para obtener más información, consulte la página del servicio de Scheduled Events en GitHub.
¿Qué es Azure Monitor para VM (versión
preliminar)?
Azure Monitor para VM supervisa las máquinas virtuales (VM ) y los conjuntos de escalado de máquinas
virtuales de Azure. El servicio analiza el rendimiento y el estado de las VM Windows y Linux, y supervisa sus
procesos y dependencias en otros recursos y procesos externos.
Permite supervisar el rendimiento y las dependencias de las aplicaciones en máquinas virtuales que están
hospedadas en el entorno local o en otro proveedor de servicios en la nube. Las siguientes características clave
ofrecen información detallada:
Gráficos de rendimiento de tendencias previamente definidos: Muestra las principales métricas de
rendimiento del sistema operativo de la VM.
Mapa de dependencias: Muestra los componentes interconectados con la VM de varios grupos de
recursos y suscripciones.
NOTE
Recientemente anunciamos cambios que estamos realizando en la característica de mantenimiento en función de los
comentarios que hemos recibido de nuestros clientes de la versión preliminar pública. Dado el número de cambios que
realizaremos, vamos a dejar de ofrecer esta característica a los nuevos clientes. Los clientes existentes pueden seguir usando
la característica de mantenimiento. Para más información, consulte las preguntas frecuentes sobre la disponibilidad general.
La integración con los registros de Azure Monitor ofrece agregación y filtrado eficaces, y puede analizar la
tendencias de los datos a lo largo del tiempo. Dicha supervisión integral de las cargas de trabajo no se puede
lograr únicamente con Azure Monitor o Service Map.
Puede ver estos datos en una sola máquina virtual directamente desde la máquina virtual, o puede usar Azure
Monitor para ofrecer una vista agregada de las máquinas virtuales; la vista admite los modos de contexto del
recurso de Azure o de contexto del área de trabajo. Para más información, consulte Introducción a los modos de
acceso.
Azure Monitor para VM puede ofrecer un rendimiento y disponibilidad predecibles de aplicaciones vitales.
Identifica los cuellos de botella del rendimiento y los problemas de red. Azure Monitor para VM también puede
ayudarle a entender si un problema está relacionado con otras dependencias.
Uso de datos
Cuando implementa Azure Monitor para VM, los datos que recopilen sus VM se ingieren y almacenan en Azure
Monitor. Los datos de rendimiento y dependencia recopilados se almacenan en un área de trabajo de Log
Analytics. Según los precios que se publican en la página de precios de Azure Monitor, Azure Monitor para VM
se factura según:
Los datos que se ingieren y almacenan.
Las reglas de alerta que se crean.
Las notificaciones que se envían.
El tamaño del registro varía en función de las longitudes de cadena de los contadores de rendimiento y puede
aumentar con el número de discos lógicos y adaptadores de red asignados a la máquina virtual. Si ya tiene un
área de trabajo y está recopilando estos contadores, no se aplicará ningún cargo duplicado. Si ya usa Service
Map, el único cambio que verá son los datos de conexión adicionales que se envían a Azure Monitor.
Pasos siguientes
Para conocer los requisitos y los métodos para habilitar la supervisión de máquinas virtuales, consulte
Implementación de Azure Monitor para VM.
Creación, visualización y administración de alertas de
métricas mediante Azure Monitor
Las alertas de métricas en Azure Monitor proporcionan una forma de recibir notificaciones cuando una de sus
métricas cruza un umbral. Las alertas de métricas funcionan en una amplia variedad de métricas de plataforma
multidimensionales, métricas personalizadas y métricas personalizadas y estándar de Application Insights. En este
artículo describiremos cómo crear, ver y administrar las reglas de alertas de métricas a través de Azure Portal y la
CLI de Azure. También puede crear reglas de alertas de métricas mediante plantillas de Azure Resource Manager
que se describe en otro artículo.
Puede obtener más información acerca del funcionamiento de las alertas de métricas en el artículo sobre
información general de las alertas de métricas.
Creación con Azure Portal

En el siguiente procedimiento se describe cómo crear una regla de alertas de métricas en Azure Portal:
1. En Azure Portal, haga clic en Monitor. La hoja Monitor consolida todas las opciones de configuración y
todos los datos de supervisión en una vista.
2. Haga clic en Alertas y, a continuación, en + Nueva regla de alertas.
TIP
La mayoría de las hojas de recursos también tienen la opción Alertas en el menú de recursos de la sección
Supervisión, de modo que también podría crear alertas desde allí.
3. Haga clic en Seleccionar destino, en el panel de contexto que se carga, y seleccione un recurso de destino
sobre el que quiera alertar. Use los menús desplegables Suscripción y Tipo de recurso para buscar el
recurso que quiere supervisar. También puede utilizar la barra de búsqueda para buscar su recurso.
4. Si el recurso seleccionado tiene métricas para las que puede crear alertas, la sección Available signals
(Señales disponibles) de la parte inferior derecha incluirá métricas. Puede ver la lista completa de tipos de
recursos compatibles con las alertas de métricas en este artículo.
5. Una vez haya seleccionado un recurso de destino, haga clic en Agregar condición.
6. Verá una lista de señales que se admiten para el recurso. Seleccione la métrica para la que quiera crear una
alerta.
7. De manera opcional, puede restringir la métrica ajustando Período y Agregación. Si la métrica tiene
dimensiones, podrá ver la tabla Dimensiones. Seleccione uno o varios valores por dimensión. La alerta de
métrica se ejecutará y evaluará la condición para todas las combinaciones de valores seleccionados.
Obtenga más información sobre cómo funciona la creación de alertas en las métricas multidimensionales.
También puede seleccionar * para cualquiera de las dimensiones. Si selecciona * , se escalará
dinámicamente la selección de todos los valores actuales y futuros de una dimensión.
8. Verá un gráfico para la métrica de las últimas 6 horas. Defina los parámetros de alerta; Tipo de condición,
Frecuencia, Operador y Umbral o Sensibilidad. Estos determinarán la lógica en la que se evaluará la
regla de alertas de métrica. Más información sobre las opciones de tipo y sensibilidad de la condición de
umbrales dinámicos.
9. Si usa un umbral estático, el gráfico de métricas puede ayudar a determinar cuál podría ser un umbral
razonable. Si usa umbrales dinámicos, el gráfico de métricas mostrará los umbrales calculados según los
datos recientes.
10. Haga clic en Listo.
11. Opcionalmente, puede agregar otro criterio si quiere supervisar una regla de alertas compleja. Actualmente
los usuarios pueden tener reglas de alertas con criterios de umbrales dinámicos como único criterio.
12. Rellene los Detalles de alertas como los campos Nombre de la regla de alertas, Descripción y
Gravedad.
13. Agregue un grupo de acciones a la alerta, ya sea seleccionando un grupo de acciones existente o creando
uno nuevo.
14. Haga clic en Listo para guardar la regla de alertas de métrica.
NOTE
Las reglas de alertas de métricas creadas mediante el portal se crean en el mismo grupo de recursos que el recurso de
destino.
Visualización y administración con Azure Portal

Puede ver y administrar las reglas de alertas de métricas mediante la hoja Administrar reglas de Alertas. En el
siguiente procedimiento se muestra cómo puede ver las reglas de alertas de métricas y editar una de ellas.
1. En Azure Portal, vaya a Monitor.
2. Haga clic en Alertas y Administrar reglas
3. En la hoja Administrar reglas, puede ver todas las reglas de alertas de las suscripciones. Puede filtrar aún
más las reglas mediante las opciones Grupo de recursos, Tipo de recurso y Recursos. Si solo quiere ver
las alertas de métricas, seleccione Métricas en Tipo de señal.
TIP
En la hoja Administrar reglas, puede seleccionar varias reglas de alertas y habilitarlas o deshabilitarlas. Esto puede
resultarle útil cuando es necesario realizar un mantenimiento de determinados recursos de destino.
4. Haga clic en el nombre de la regla de alertas de métricas que quiera editar.

5. En la regla Editar, haga clic en los criterios de alerta que quiera editar. Puede cambiar la métrica, la
condición de umbral y otros campos según sea necesario
NOTE
No puede editar el recurso de destino y el nombre de la regla de alertas después de crear la alerta de métrica.
6. Haga clic en Listo para guardar los cambios.
Con la CLI de Azure

En las secciones anteriores se describía cómo crear, ver y administrar las reglas de alertas de métricas mediante
Azure Portal. En esta sección se describe cómo hacer lo mismo con la multiplataforma CLI de Azure. La forma más
rápida de comenzar a utilizar la CLI de Azure es a través de Azure Cloud Shell. En este artículo, usamos Cloud
Shell.
1. Vaya a Azure portal y haga clic en Cloud Shell.
2. En el símbolo del sistema, puede usar los comandos con la opción --help para obtener más información
sobre el comando y cómo usarlo. Por ejemplo, el comando siguiente muestra la lista de comandos
disponibles para crear, ver y administrar alertas de métricas.
az monitor metrics alert --help
3. Puede crear una regla de alertas de métricas sencilla que supervise si el porcentaje medio de la CPU en una
máquina virtual es mayor que 90.
az monitor metrics alert create -n {nameofthealert} -g {ResourceGroup} --scopes

{VirtualMachineResourceID} --condition "avg Percentage CPU > 90" --description {descriptionofthealert}
4. Puede ver todas las alertas de métricas en un grupo de recursos con el siguiente comando.
az monitor metrics alert list -g {ResourceGroup}
5. Puede ver los detalles de una regla de alertas métricas determinada mediante el nombre o el identificador
del recurso de la regla.
az monitor metrics alert show -g {ResourceGroup} -n {AlertRuleName}
az monitor metrics alert show --ids {RuleResourceId}
6. Puede deshabilitar una regla de alertas de métricas con el comando siguiente.
az monitor metrics alert update -g {ResourceGroup} -n {AlertRuleName} --enabled false
7. Puede eliminar una regla de alertas de métricas con el comando siguiente.
az monitor metrics alert delete -g {ResourceGroup} -n {AlertRuleName}
Pasos siguientes
Creación de alertas de métricas con plantillas de Azure Resource Manager.
Comprender cómo funcionan las alertas de métricas.
Cómo funcionan las alertas de métricas con la condición de umbrales dinámicos.
Comprender el esquema de webhook para las alertas de métricas
Creación, visualización y administración de alertas de
registro mediante Azure Monitor
En este artículo se muestra cómo configurar las alertas de registro con la interfaz de alertas en Azure Portal. La
definición de una regla de alertas consta de tres partes:
Destino: recurso de Azure específico que se va a supervisar.
Criterios: condición o lógica específicas que, cuando se señaliza la alerta, deben desencadenar una acción.
Acción: llamada específica enviada a un receptor de una notificación (correo electrónico, SMS, webhook, etc.).
El término Alertas de registro se usa para describir las alertas cuya señal es una consulta de registro basada en
un área de trabajo de Log Analytics o en Application Insights. Obtenga más información acerca de la funcionalidad,
la terminología y los tipos de Alertas de registro: información general.
NOTE
Ahora los datos de registro populares de un área de trabajo de Log Analytics también están disponibles en la plataforma de
métricas de Azure Monitor. Para obtener más detalles, consulte Alerta de métricas de los registros.
Administración de las alertas de registro desde Azure Portal

A continuación, se muestra una guía paso a paso acerca de cómo usar las alertas de registro mediante la interfaz
de Azure Portal.
Creación de una regla de alertas de registro en Azure Portal
1. En Azure Portal, seleccione Supervisar y, en la sección SUPERVISAR, elija Alertas.
2. Seleccione el botón Nueva regla de alertas para crear una alerta en Azure.
3. La sección Crear alerta se muestra con tres partes, que constan de: definición de la condición de alerta,
definición de los detalles de la alerta y definición del grupo de acciones.
4. Para definir la condición de la alerta, use primero el vínculo Seleccionar recurso y especifique el destino
mediante la selección de un recurso. Para filtrar, elija la Suscripción, el Tipo de recurso y el Recurso necesario.
NOTE
Para crear una alerta de registro, compruebe la señal de registro disponible para el recurso seleccionado antes de
continuar.
5. Alertas de registro: asegúrese de que la opción Tipo de recurso sea un origen de análisis como Log
Analytics o Application Insights y el tipo de señal sea Registro; después, una vez elegido el recurso
apropiado, haga clic en Listo. A continuación, use el botón Agregar criterios para ver la lista de opciones de
señal disponibles para el recurso y, de la lista de señales, la opción Búsqueda de registros personalizada
para el servicio de supervisión del registro, como Log Analytics o Application Insights.
NOTE
Las listas de las alertas pueden importar una consulta de análisis como tipo de señal ( Log (Saved Query) (Registro
[consulta guardada])), tal como se muestra en la ilustración anterior. Por tanto, los usuarios pueden perfeccionar la
consulta en Analytics y luego guardarla para usarla en alertas en otro momento. Puede encontrar más detalles sobre
el uso de consultas guardadas en Introducción a las consultas de registro en Azure Monitor o Consulta compartida
en Analytics de Application Insights.
6. Alertas de registro: una vez seleccionada esta opción, la consulta de alertas se puede indicar en el campo
Consulta de búsqueda; si la sintaxis de la consulta es incorrecta, en el campo aparece el error en ROJO. Si
la sintaxis de consulta es correcta, como referencia, se muestran los datos históricos de la consulta indicada
en formato de gráfico con la opción de retocar la ventana de tiempo desde las últimas seis horas hasta la
última semana.
NOTE
La visualización de los datos históricos solo se muestra si los resultados de la consulta tienen detalles temporales. Si la
consulta genera datos resumidos o valores de columna específicos, estos se representan en un gráfico singular. Para el
tipo Unidades métricas de Alertas de registro con Application Insights o que cambiaron a la nueva API, puede
especificar por cuál variable concreta desea agrupar los datos mediante la opción Agregado en, tal y como se ilustra
a continuación:
7. Alertas de registro: Con la visualización activada, se puede seleccionar la Lógica de alerta de entre las
opciones mostradas de Condición, Agregación y, por último, Umbral. Por último, especifique en la lógica el
tiempo para evaluar la condición especificada mediante la opción Periodo. Además, especifique la
frecuencia con que debe ejecutarse la alerta seleccionando la opción adecuada en el campo Frecuencia. Las
alertas de registro se pueden basar en lo siguiente:
Número de registros: se crea una alerta si el número de registros devueltos por la consulta es mayor o
menor que el valor que proporcione.
Unidades métricas: se crea una alerta si cada valor agregado en los resultados excede el valor de umbral
proporcionado y se agrupa por el valor elegido. El número de infracciones de una alerta es el número de
veces que se supera el umbral en el período de tiempo seleccionado. Puede especificar Infracciones
totales para cualquier combinación de infracciones en el conjunto de resultados o Infracciones
consecutivas para que las infracciones deban tener lugar en muestras consecutivas.
8. En segundo lugar, asigne un nombre a la alerta en el campo Nombre de la regla de alertas junto con una
Descripción, en la que debe proporcionar información específica sobre la alerta, y debe indicar también un
valor de Gravedad entre las opciones proporcionadas. Estos detalles se reutilizan en todos los correos
electrónicos, las notificaciones o las notificaciones push de alerta enviados por Azure Monitor. Además, el
usuario puede elegir activar inmediatamente la regla de alertas al crearla cambiando la opción Habilitar
regla tras la creación según corresponda.
Solo para las alertas de registro, se encuentra disponible alguna funcionalidad adicional en los detalles de
la alerta:
Suprimir alertas: Al activar la supresión de la regla de alerta, las acciones de la regla se deshabilitan
durante un período de tiempo definido después de crear una nueva alerta. La regla se sigue
ejecutando y crea registros de alerta si se cumplen los criterios. De esta forma, dispone de tiempo
para corregir el problema sin ejecutar acciones duplicadas.
TIP
Especifique un valor de desactivar las alertas mayor que la frecuencia de alertas para garantizar que las
notificaciones se detengan sin superposición
9. Como tercer y último paso, especifique si es necesario desencadenar algún grupo de acciones para la regla
de alertas si se cumple la condición de alerta. Puede elegir cualquier grupo de acciones existente con alerta
o crear uno. Según el grupo de acciones seleccionado, cuando se desencadena la alerta, Azure: envía correos
electrónicos, envía SMS, llama a webhooks, la soluciona con runbooks de Azure, envía notificaciones push a
la herramienta de ITSM, etc. Obtenga más información sobre los grupos de acciones.
NOTE
Consulte los límites de servicio de suscripción de Azure para conocer los límites relacionados con las cargas de
runbook desencadenadas para las alertas de registro a través de grupos de acciones de Azure.
Para las alertas de registro, se encuentra disponible alguna funcionalidad adicional para reemplazar las
acciones predeterminadas:
Notificación por correo electrónico: invalida el asunto del correo electrónico en el correo
electrónico, enviado a través del grupo de acciones, si existen una o más acciones de correo
electrónico en dicho grupo de acciones. No se puede modificar el cuerpo del mensaje de correo y este
campo no es para la dirección de correo electrónico.
Incluir carga de JSON personalizada: invalida el webhook JSON usado por los grupos de
acciones si una o varias acciones de webhook existen en el grupo de acciones mencionado. El usuario
puede especificar el formato JSON que se usará para todos los webhooks configurados en el grupo
de acciones asociado; para más información sobre los formatos de webhook, consulte Acciones de
webhook para alertas de registro. La opción de vista de webhook se proporciona para comprobar el
formato con datos JSON de ejemplo.
10. Si todos los campos son válidos y tienen una marca verde, se puede hacer clic en el botón Crear regla de
alertas y se crea la alerta en Azure Monitor: Alertas. Todas las alertas pueden verse en el panel de las
alertas.
En cuestión de minutos, se activa la alerta y se desencadena tal como se describió anteriormente.

Los usuarios también pueden finalizar la consulta de análisis en Log Analytics e insertarla para crear una alerta a
través del botón "Establecer alerta" y, a continuación, seguir las instrucciones del paso 6 en adelante del tutorial
anterior.
Visualización y administración de las alertas de registro en Azure Portal

1. En Azure Portal, seleccione Supervisar y, en la sección SUPERVISAR, elija Alertas.
2. Se muestra el panel de alertas, de forma que aparecen todas las alertas de Azure (incluidas las alertas de
registro) en un único panel, incluidas todas las instancias de cuando se ha activado la regla de la alerta de
registro. Para obtener más información, consulte Alert Management.
NOTE
Las reglas de la alerta de registro se componen de una lógica personalizada basada en la consulta proporcionada por
los usuarios y, por lo tanto, sin un estado resuelto. Debido a esto, cada vez que se cumplen las condiciones
especificadas en la regla de la alerta de registro, se activa.
3. Seleccione el botón Administrar reglas situado en la barra superior para navegar hasta la sección de
administración de reglas, donde se enumeran todas las reglas de alerta creadas, incluidas las alertas que se
han deshabilitado.
Administración de alertas de registro mediante la plantilla de recursos

de Azure
Las alertas del registro de Azure Monitor están asociadas con el tipo de recurso
Microsoft.Insights/scheduledQueryRules/ . Para más información sobre este tipo de recurso, vea Azure Monitor:
referencia de la API de reglas de consulta programada. Las alertas de registro de Application Insights o Log
Analytics se pueden crear mediante la API de Reglas de consulta programadas.
NOTE
Las alertas de registro de Log Analytics también se puede administrar mediante Alert API de Log Analytics y las plantillas
heredadas de búsquedas y alertas guardadas de Log Analytics también. Para más información acerca del uso de la nueva API
de Reglas de consulta programadas detallada aquí de forma predeterminada, consulte Switch to new API for Log Analytics
Alerts (Cambio a una API nueva de alertas de Log Analytics).
Creación de una alerta de registro de ejemplo mediante la plantilla de recursos de Azure

Esta es la estructura de la plantilla de recursos basada en la creación de reglas de consulta programada mediante
una consulta de búsqueda de registros estándar de una alerta de registro del tipo número de resultados, con datos
de ejemplo establecidos como variables.
{
"parameters": {
},
"variables": {
"alertLocation": "southcentralus",
"alertName": "samplelogalert",
"alertDescription": "Sample log search alert",
"alertStatus": "true",
"alertSource":{
"Query":"requests",
"SourceId": "/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/myRG/providers/microsoft.insights/components/sampleAIapplication",
"Type":"ResultCount"
},
"alertSchedule":{
"Frequency": 15,
"Time": 60
},
"alertActions":{
"SeverityLevel": "4"
},
"alertTrigger":{
"Operator":"GreaterThan",
"Threshold":"1"
},
"actionGrp":{
"ActionGroup": "/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/myRG/providers/microsoft.insights/actiongroups/sampleAG",
"Subject": "Customized Email Header",
"Webhook": "{ \"alertname\":\"#alertrulename\", \"IncludeSearchResults\":true }"
}
},
"resources":[ {
"name":"[variables('alertName')]",
"type":"Microsoft.Insights/scheduledQueryRules",
"apiVersion": "2018-04-16",
"location": "[variables('alertLocation')]",
"properties":{
"description": "[variables('alertDescription')]",
"enabled": "[variables('alertStatus')]",
"source": {
"query": "[variables('alertSource').Query]",
"dataSourceId": "[variables('alertSource').SourceId]",
"queryType":"[variables('alertSource').Type]"
},
"schedule":{
"frequencyInMinutes": "[variables('alertSchedule').Frequency]",
"timeWindowInMinutes": "[variables('alertSchedule').Time]"
},
"action":{
"odata.type":
"Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.Microsoft.AppInsights.Nexus.DataContracts.Resources
.ScheduledQueryRules.AlertingAction",
"severity":"[variables('alertActions').SeverityLevel]",
"aznsAction":{
"actionGroup":"[array(variables('actionGrp').ActionGroup)]",
"emailSubject":"[variables('actionGrp').Subject]",
"customWebhookPayload":"[variables('actionGrp').Webhook]"
},
"trigger":{
"thresholdOperator":"[variables('alertTrigger').Operator]",
"threshold":"[variables('alertTrigger').Threshold]"
}
}
}
} ]
}
El JSON del ejemplo anterior puede guardarse como (digamos) sampleScheduledQueryRule.json a efectos de este
tutorial y puede implementarse mediante Azure Resource Manager en Azure Portal.
Alerta de registro con consulta entre registros mediante la plantilla de recursos de Azure
Esta es la estructura de la plantilla de recursos basada en la creación de reglas de consulta programada mediante
una consulta de búsqueda de registros entre recursos de una alerta de registro del tipo unidad métrica, con datos
de ejemplo establecidos como variables.
{
"parameters": {
},
"variables": {
"alertLocation": "Region Name for your Application Insights App or Log Analytics Workspace",
"alertName": "sample log alert",
"alertDescr": "Sample log search alert",
"alertStatus": "true",
"alertSource":{
"Query":"union workspace(\"servicews\").Update, app('serviceapp').requests | summarize
AggregatedValue = count() by bin(TimeGenerated,1h), Classification",
"Resource1": "/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/contosoRG/providers/microsoft.OperationalInsights/workspaces/servicews",
"Resource2": "/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/contosoRG/providers/microsoft.insights/components/serviceapp",
"SourceId": "/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/contosoRG/providers/microsoft.OperationalInsights/workspaces/servicews",
"Type":"ResultCount"
},
"alertSchedule":{
"Frequency": 15,
"Time": 60
},
"alertActions":{
"SeverityLevel": "4",
"SuppressTimeinMin": 20
},
"alertTrigger":{
"Operator":"GreaterThan",
"Threshold":"1"
},
"metricMeasurement": {
"thresholdOperator": "Equal",
"threshold": "1",
"metricTriggerType": "Consecutive",
"metricColumn": "Classification"
},
"actionGrp":{
"ActionGroup": "/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/contosoRG/providers/microsoft.insights/actiongroups/sampleAG",
"Subject": "Customized Email Header",
"Webhook": "{ \"alertname\":\"#alertrulename\", \"IncludeSearchResults\":true }"
}
},
"resources":[ {
"name":"[variables('alertName')]",
"type":"Microsoft.Insights/scheduledQueryRules",
"apiVersion": "2018-04-16",
"location": "[variables('alertLocation')]",
"properties":{
"description": "[variables('alertDescr')]",
"enabled": "[variables('alertStatus')]",
"source": {
"query": "[variables('alertSource').Query]",
"authorizedResources": "[concat(array(variables('alertSource').Resource1),
array(variables('alertSource').Resource2))]",
"dataSourceId": "[variables('alertSource').SourceId]",
"queryType":"[variables('alertSource').Type]"
},
"schedule":{
"frequencyInMinutes": "[variables('alertSchedule').Frequency]",
"timeWindowInMinutes": "[variables('alertSchedule').Time]"
},
"action":{
"odata.type":
"Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.Microsoft.AppInsights.Nexus.DataContracts.Resources
.ScheduledQueryRules.AlertingAction",
"severity":"[variables('alertActions').SeverityLevel]",
"throttlingInMin": "[variables('alertActions').SuppressTimeinMin]",
"aznsAction":{
"actionGroup": "[array(variables('actionGrp').ActionGroup)]",
"emailSubject":"[variables('actionGrp').Subject]",
"customWebhookPayload":"[variables('actionGrp').Webhook]"
},
"trigger":{
"thresholdOperator":"[variables('alertTrigger').Operator]",
"threshold":"[variables('alertTrigger').Threshold]",
"metricTrigger":{
"thresholdOperator": "[variables('metricMeasurement').thresholdOperator]",
"threshold": "[variables('metricMeasurement').threshold]",
"metricColumn": "[variables('metricMeasurement').metricColumn]",
"metricTriggerType": "[variables('metricMeasurement').metricTriggerType]"
}
}
}
}
} ]
}
IMPORTANT
Si usa una consulta entre recursos en la alerta de registros, el uso de authorizedResources es obligatorio y el usuario debe
acceder a la lista de los recursos indicados.
El JSON del ejemplo anterior puede guardarse como (digamos) sampleScheduledQueryRule.json a efectos de este
tutorial y puede implementarse mediante Azure Resource Manager en Azure Portal.
Administración de alertas de registro con PowerShell

NOTE
Azure Monitor: API de Reglas de consulta programadas es una API REST totalmente compatible con la API REST
de Azure Resource Manager. Y los cmdlets de PowerShell que se enumeran a continuación están disponibles para
aprovechar la API de Reglas de consulta programadas.
1. New -AzScheduledQueryRule: cmdlet de PowerShell para crear una nueva regla de alerta de registro.
2. Set-AzScheduledQueryRule: cmdlet de PowerShell para actualizar una regla de alerta de registro.
3. New -AzScheduledQueryRuleSource: cmdlet de PowerShell para crear o actualizar el objeto que especifica los
parámetros de origen para una alerta de registro. Se usa como entrada en los cmdlets New -
AzScheduledQueryRule y Set-AzScheduledQueryRule.
4. New -AzScheduledQueryRuleSchedule: cmdlet de PowerShell para crear o actualizar el objeto que especifica los
parámetros de programación para una alerta de registro. Se usa como entrada en los cmdlets New -
5. New -AzScheduledQueryRuleAlertingAction: cmdlet de PowerShell para crear o actualizar el objeto que
especifica los parámetros de acción para una alerta de registro. Se usa como entrada en los cmdlets New -
6. New -AzScheduledQueryRuleAznsActionGroup: cmdlet de PowerShell para crear o actualizar el objeto que
especifica los parámetros de grupos para una alerta de registro. Se usa como entrada en el cmdlet New -
AzScheduledQueryRuleAlertingAction.
7. New -AzScheduledQueryRuleTriggerCondition: cmdlet de PowerShell para crear o actualizar el objeto que
especifica los parámetros de condición de desencadenador para una alerta de registro. Se usa como entrada en
el cmdlet New -AzScheduledQueryRuleAlertingAction.
8. New -AzScheduledQueryRuleLogMetricTrigger: cmdlet de PowerShell para crear o actualizar el objeto que
especifica los parámetros de condición de desencadenador para una alerta de registro de tipo de medida de
métrica. Se usa como entrada en el cmdlet New -AzScheduledQueryRuleTriggerCondition.
9. Get-AzScheduledQueryRule: cmdlet de PowerShell para enumerar las reglas de alerta de registro o una regla
de alerta de registro específica
10. Update-AzScheduledQueryRule: cmdlet de PowerShell para habilitar o deshabilitar la regla de alerta de registro
11. Remove-AzScheduledQueryRule: cmdlet de PowerShell para eliminar una regla de alerta de registro
NOTE
Los cmdlets de PowerShell ScheduledQueryRules solo pueden administrar las reglas creadas por el propio cmdlet o mediante
Azure Monitor: API de Reglas de consulta programadas. Las reglas de alerta de registro creadas con la API de alertas de Log
Analytics antiguas y las plantillas antiguas de alertas y búsquedas guardadas de Log Analytics pueden administrarse
mediante los cmdlets de PowerShell ScheduledQueryRules solo después de que el usuario cambie la preferencia de API a las
alertas de Log Analytics.
A continuación, se muestran los pasos para crear una regla de alertas de registro de ejemplo con los cmdlets
scheduledQueryRules de PowerShell.
$source = New-AzScheduledQueryRuleSource -Query 'Heartbeat | summarize AggregatedValue = count() by

bin(TimeGenerated, 5m), _ResourceId' -DataSourceId "/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/contosoRG/providers/microsoft.OperationalInsights/workspaces/servicews"
$schedule = New-AzScheduledQueryRuleSchedule -FrequencyInMinutes 15 -TimeWindowInMinutes 30
$metricTrigger = New-AzScheduledQueryRuleLogMetricTrigger -ThresholdOperator "GreaterThan" -Threshold 2 -

MetricTriggerType "Consecutive" -MetricColumn "_ResourceId"
$triggerCondition = New-AzScheduledQueryRuleTriggerCondition -ThresholdOperator "LessThan" -Threshold 5 -

MetricTrigger $metricTrigger
$aznsActionGroup = New-AzScheduledQueryRuleAznsActionGroup -ActionGroup "/subscriptions/a123d7efg-123c-1234-

5678-a12bc3defgh4/resourceGroups/contosoRG/providers/microsoft.insights/actiongroups/sampleAG" -EmailSubject
"Custom email subject" -CustomWebhookPayload "{ \"alert\":\"#alertrulename\", \"IncludeSearchResults\":true }"
$alertingAction = New-AzScheduledQueryRuleAlertingAction -AznsAction $aznsActionGroup -Severity "3" -Trigger

$triggerCondition
New-AzScheduledQueryRule -ResourceGroupName "contosoRG" -Location "Region Name for your Application Insights
App or Log Analytics Workspace" -Action $alertingAction -Enabled $true -Description "Alert description" -
Schedule $schedule -Source $source -Name "Alert Name"
Administración de alertas de registro con la CLI o la API

Azure Monitor: API de Reglas de consulta programadas es una API REST totalmente compatible con la API REST
de Azure Resource Manager. Por lo tanto, se puede utilizar a través de Powershell con los comandos de Resource
Manager para la CLI de Azure.
NOTE
Las alertas de registro de Log Analytics también se puede administrar mediante Alert API de Log Analytics y las plantillas
heredadas de búsquedas y alertas guardadas de Log Analytics también. Para más información acerca del uso de la nueva API
de Reglas de consulta programadas detallada aquí de forma predeterminada, consulte Switch to new API for Log Analytics
Alerts (Cambio a una API nueva de alertas de Log Analytics).
Actualmente, las alertas de registro no tienen comandos de la CLI dedicados; pero, como se muestra a
continuación, se pueden usar mediante el cmdlet de la CLI de Azure Resource Manager para la plantilla de
recursos de muestra que se mostró anteriormente (sampleScheduledQueryRule.json) en la sección Plantilla de
recursos:
az group deployment create --resource-group contosoRG --template-file sampleScheduledQueryRule.json
Si la operación se realiza correctamente, se devolverá 201 para indicar que se ha creado la regla de alertas o 200 si
se ha modificado una regla de alerta existente.
Pasos siguientes
Más información sobre las alertas de registro en las alertas de Azure.
Conocer las acciones de webhook para alertas de registro
Más información sobre Application Insights
Obtenga más información sobre las consultas de registro.
Introducción a la galería de imágenes compartidas
La galería de imágenes compartidas es un servicio que ayuda a crear la estructura y la organización en torno a
las imágenes administradas. Las galerías de imágenes compartidas proporcionan:
Replicación global administrada de las imágenes.
Control de versiones y agrupación de las imágenes para facilitar la administración.
Imágenes de alta disponibilidad con cuentas de almacenamiento con redundancia de zona (ZRS ) en las
regiones donde esté disponible Availability Zones. ZRS ofrece más resistencia a errores de zona.
Imágenes compartidas entre suscripciones e, incluso, entre inquilinos de Active Directory (AD ) mediante
RBAC.
Escalado de las implementaciones con réplicas de imagen en cada región.
Uso de una galería de imágenes compartidas para compartir imágenes con diferentes usuarios, entidades de
servicio o grupos de AD dentro de su organización. Las imágenes compartidas se pueden replicar en varias
regiones, para un escalado más rápido de las implementaciones.
Una imagen administrada es una copia de una VM completa (incluidos los discos de datos asociados) o,
simplemente, el disco del sistema operativo, según cómo cree la imagen. Cuando crea una VM desde la imagen,
la copia de los VHD de la imagen se usa para crear los discos para la nueva VM. La imagen administrada
permanece en el almacenamiento y puede usarse una y otra vez para crear nuevas VM.
Si tiene un gran número de imágenes administradas que se deben mantener y quiere que estén disponibles en
toda la empresa, puede usar una galería de imágenes compartidas como repositorio que facilite la tarea de
compartir las imágenes.
La característica de galería de imágenes compartidas tiene varios tipos de recursos:
RESOURCE DESCRIPCIÓN
Imagen administrada Una imagen básica que se puede usar por sí sola o para crear
una versión de imagen de una galería de imágenes. Las
imágenes administradas se crean a partir de máquinas
virtuales generalizadas. Una imagen administrada es un tipo
de VHD especial que se puede usar para crear varias
máquinas virtuales y que ahora se puede usar para crear
versiones de imágenes compartidas.
Instantánea Una copia de un disco duro virtual que se puede usar para
crear una versión de imagen. Las instantáneas pueden
tomarse de una máquina virtual especializada (una que no se
ha generalizado) y, luego, usarse por sí sola o con
instantáneas de discos de datos para crear una versión de
imagen especializada.
Galería de imágenes Al igual que Azure Marketplace, una galería de imágenes

es un repositorio para administrar y compartir imágenes,
pero usted puede controlar quién tiene acceso.
Definición de la imagen Las imágenes se definen dentro de una galería y contienen

información sobre la imagen y los requisitos para usarla en la
organización. Puede incluir información como si la imagen es
generalizada o especializada, el sistema operativo, los
requisitos de memoria mínima y máxima y las notas de la
versión. Es una definición de un tipo de imagen.
Versión de la imagen Una versión de la imagen es lo que se usa para crear una
VM cuando se usa una galería. Puede tener varias versiones
de una imagen según sea necesario para su entorno. Al igual
que una imagen administrada, cuando se usa una versión
de la imagen para crear una VM, la versión de la imagen se
usa para crear nuevos discos para la VM. Las versiones de las
imágenes pueden usarse varias veces.
Definiciones de imagen
Las definiciones de la imagen son una agrupación lógica de las versiones de una imagen. La definición de la
imagen contiene información acerca de por qué se creó la imagen, para qué sistema operativo sirve e
información acerca del uso de la imagen. Una definición de imagen es como un plan para todos los detalles que
rodean la creación de una imagen específica. No se implementa una máquina virtual desde una definición de
imagen, sino desde la versión de imagen creada a partir de la definición.
Hay tres parámetros para cada definición de imagen que se usan en combinación: Publisher, Offer y SKU. Se
utilizan para buscar una definición de imagen específica. Puede tener versiones de imágenes que comparten uno
o dos valores, pero no los tres. Por ejemplo, estas son las tres definiciones de imágenes y sus valores:
DEFINICIÓN DE IMÁGENES PUBLICADOR OFERTA SKU
myImage1 Contoso Finance Back-end
myImage2 Contoso Finance Front-end
myImage3 Prueba Finance Front-end

Los tres tienen conjuntos de valores únicos. El formato es similar a cómo puede especificar actualmente el editor,
la oferta y la SKU para las imágenes de Azure Marketplace en Azure PowerShell para obtener la última versión
de una imagen de Marketplace. Cada definición de imagen debe tener un conjunto único de estos valores.
Los siguientes son otros parámetros que se pueden establecer en la definición de la imagen para que pueda
realizar un seguimiento más sencillo de sus recursos:
Estado del sistema operativo: puede establecer el estado del sistema operativo en generalizado o
especializado.
Sistema operativo: puede ser Windows o Linux.
Descripción: la descripción de uso para proporcionar información más detallada sobre por qué existe la
definición de la imagen. Por ejemplo, podría tener una definición de la imagen para el servidor front-end que
tenga la aplicación preinstalada.
CLUF: puede utilizarse para señalar un contrato de licencia de usuario final específico para la definición de la
imagen.
Declaración de privacidad y Notas de la versión: almacene las notas de la versión y las declaraciones de
privacidad en el almacenamiento Azure y proporcione un identificador URI para acceder a ellas como parte
de la definición de imagen.
Fecha del final de la duración: adjunte una fecha del final de la duración a la definición de imagen para poder
utilizar la automatización y eliminar las definiciones de imagen antiguas.
Etiqueta: puede agregar etiquetas al crear la definición de imagen. Para más información sobre las etiquetas,
consulte Uso de etiquetas para organizar los recursos.
Número mínimo y máximo de vCPU y recomendaciones de memoria: si la imagen tiene vCPU y
recomendaciones de memoria, puede adjuntar esa información a la definición de imagen.
Tipos de disco no permitidos: puede proporcionar información acerca de las necesidades de almacenamiento
para la máquina virtual. Por ejemplo, si la imagen no es adecuada para los discos HDD estándar, agréguelos a
la lista de no permitidos.
Imágenes generalizadas y especializadas

Hay dos estados del sistema operativo compatibles con Shared Image Gallery. Normalmente, las imágenes
requieren que la máquina virtual usada para crear la imagen se haya generalizado antes de tomar la imagen. La
generalización es un proceso que quita la información específica del equipo y del usuario de la máquina virtual.
En Windows, se usa también Sysprep. En el caso de Linux, puede usar los parámetros waagent -deprovision o
-deprovision+user .
Las máquinas virtuales especializadas no han pasado por un proceso para quitar la información y las cuentas
específicas de la máquina. Además, las máquinas virtuales creadas a partir de imágenes especializadas no tienen
un osProfile asociado a ellas. Esto significa que las imágenes especializadas tendrán algunas limitaciones.
Las cuentas que se podrían usar para iniciar sesión en la máquina virtual también se pueden usar en
cualquier máquina virtual creada mediante la imagen especializada que se crea a partir de esa máquina
virtual.
Las máquinas virtuales tendrán el nombre de equipo de la máquina virtual de la que se tomó la imagen.
Debe cambiar el nombre de equipo para evitar colisiones.
osProfile es la forma en que se pasa información confidencial a la máquina virtual, mediante secrets . Esto
puede producir problemas al usar KeyVault, WinRM y otras funciones que usan secrets en osProfile . En
algunos casos, puede usar identidades Managed Service Identity (MSI) para solucionar estas limitaciones.
IMPORTANT
Las imágenes especializadas están actualmente en versión preliminar pública. Esta versión preliminar se ofrece sin Acuerdo
Limitaciones conocidas de la versión preliminar Las máquinas virtuales solo se pueden crear a partir de imágenes
especializadas mediante el portal o la API. No hay compatibilidad con la CLI ni con PowerShell para la versión preliminar.
Compatibilidad regional
Las regiones de origen se muestran en la tabla siguiente. Todas las regiones públicas pueden ser regiones de
destino, pero para replicar en el Centro de Australia y Centro de Australia 2 debe tener su suscripción en la lista
de permitidos. Para solicitar la inclusión en la lista blanca, visite: https://azure.microsoft.com/global-
infrastructure/australia/contact/
REGIONES DE ORIGEN
Centro de Australia Este de China Sur de la India Europa occidental
Centro de Australia 2 Este de China 2 Sudeste asiático Sur de Reino Unido 2
Este de Australia Norte de China Este de Japón Oeste de Reino Unido
Sudeste de Australia Norte de China 2 Oeste de Japón Departamento de Defensa

de EE. UU. Centro
Sur de Brasil Asia oriental Corea Central Departamento de Defensa

de EE. UU. Este
Centro de Canadá East US Corea del Sur Gobierno de EE. UU.:

Arizona
Este de Canadá Este de EE. UU. 2 Centro-Norte de EE. UU Gobierno de EE. UU.: Texas
India Central EUAP de Este de EE. UU. 2 Europa del Norte Gobierno de EE. UU. -
Virginia
Centro de EE. UU. Centro de Francia Centro-Sur de EE. UU Oeste de la India
EUAP del centro de EE. UU. Sur de Francia Centro occidental de EE.UU. Oeste de EE. UU.
Oeste de EE. UU. 2
límites
Hay límites por suscripción, para implementar los recursos con las galerías de imágenes compartidas:
100 galerías de imágenes compartidas por suscripción, por región
1000 definiciones de imágenes por suscripción, por región
10 000 versiones de imágenes por suscripción, por región
Para más información, consulte Comparación del uso de recursos con los límites para obtener ejemplos sobre
cómo comprobar el uso actual.
Escalado
La galería de imágenes compartidas le permite especificar el número de réplicas de las imágenes que quiere que
Azure mantenga. Esto ayuda en los escenarios de implementación de varias VM, ya que las implementaciones
de VM se pueden distribuir a las distintas réplicas, lo que reduce la probabilidad de que el proceso de creación
de instancias quede limitado por la sobrecarga de una única réplica.
Con la galería de imágenes compartidas, ahora puede implementar hasta 1000 instancias de máquinas virtuales
en una conjunto de escalado de máquinas virtuales (a partir de 600 con imágenes administradas). Las réplicas
de imágenes proporcionan un mejor rendimiento de implementación, confiabilidad y coherencia. Puede
establecer un número de réplicas diferente en cada región de destino, en función de las necesidades de escala de
la región. Dado que cada réplica es una copia en profundidad de la imagen, esto ayuda a escalar las
implementaciones linealmente con cada réplica adicional. Aunque entendemos que no hay dos imágenes o
regiones iguales, he aquí nuestra guía general sobre cómo usar réplicas en una región:
En el caso de las implementaciones de conjunto de escalado de máquinas virtuales (VMSS ), se recomienda
mantener una réplica por cada 20 máquinas virtuales que cree simultáneamente. Por ejemplo, si va a crear
120 máquinas virtuales simultáneamente mediante la misma imagen en una región, se recomienda
conservar al menos seis réplicas de la imagen.
Para las implementaciones de un conjunto de escalado de máquinas virtuales, para cada conjunto con hasta
600 instancias, se recomienda conservar al menos una réplica. Por ejemplo, si va a crear cinco conjuntos de
escalado de forma simultánea, cada uno con 600 instancias de máquinas virtuales con la misma imagen en
una única región, se recomienda conservar al menos cinco réplicas de la imagen.
Siempre se recomienda aprovisionar en exceso el número de réplicas debido a factores como el tamaño de la
imagen, el contenido y el tipo de sistema operativo.
Hacer que las imágenes tengan alta disponibilidad

El almacenamiento con redundancia de zona (ZRS ) de Azure proporciona resistencia frente a un error de la zona
de disponibilidad en la región. Con la disponibilidad general de la galería de imágenes compartidas, puede elegir
almacenar sus imágenes en cuentas de ZRS en regiones con zonas de disponibilidad.
También puede elegir el tipo de cuenta para cada una de las regiones de destino. El tipo de cuenta de
almacenamiento predeterminado es Standard_LRS, pero puede elegir Standard_ZRS para regiones con zonas
de disponibilidad. Compruebe la disponibilidad regional de ZRS aquí.
Replicación
La galería de imágenes compartidas también permite replicar las imágenes en otras regiones de Azure
automáticamente. Cada versión de una imagen compartida se puede replicar en distintas regiones en función de
lo que sea más conveniente para su organización. Un ejemplo es replicar siempre la imagen más reciente en
varias regiones, mientras que todas las versiones anteriores solo están disponibles en una región. Esto puede
ayudar a ahorrar costos de almacenamiento para las versiones de imágenes compartidas.
Las regiones donde puede replicarse la versión de una imagen compartida se pueden actualizar después de su
creación. El tiempo necesario para replicar en diferentes regiones depende de la cantidad de datos que se copien
y del número de regiones en las que se replicará la versión. En algunos casos, esto puede tardar varias horas.
Mientras se produce la replicación, puede ver el estado de replicación por región. Una vez que se complete la
replicación de la imagen en una región, podrá implementar una máquina virtual o conjunto de escalado con esa
versión de la imagen en la región.
Access
Dado que la galería de imágenes compartidas, la definición de la imagen y la versión de la imagen son recursos,
pueden compartirse con los controles integrados nativos de Azure RBAC. Con RBAC puede compartir estos
recursos con otros usuarios, entidades de servicio y grupos. Incluso se puede compartir el acceso a personas
ajenas al inquilino en el que se crearon. Cuando el usuario tiene acceso a la versión de las imágenes
compartidas, puede implementar una máquina virtual o un conjunto de escalado de máquinas virtuales. Aquí
está la matriz de uso compartido que ayuda a entender a lo que el usuario tiene acceso:
COMPARTIDO CON EL GALERÍA DE IMÁGENES

USUARIO COMPARTIDAS DEFINICIÓN DE IMÁGENES VERSIÓN DE LA IMAGEN
Galería de imágenes Sí Sí Sí
compartidas
Definición de imágenes Sin Sí Sí
Se recomienda el uso compartido en el nivel de la galería para una mejor experiencia. No se recomienda
compartir las versiones individuales de la imagen. Para más información, consulte Administración del acceso a
los recursos de Azure mediante RBAC.
Las imágenes también se pueden compartir, a escala, incluso entre inquilinos mediante un registro de aplicación
de varios inquilinos. Para más información acerca de cómo compartir imágenes entre los inquilinos, consulte
Compartir imágenes de máquina virtual de la galería en inquilinos de Azure.
Facturación
No hay ningún cargo adicional por usar el servicio de la galería de imágenes compartidas. Se le cobrará por los
siguientes recursos:
Costos de almacenamiento de las versiones de imágenes compartidas. El costo depende del número de
réplicas de la versión de la imagen y del número de regiones en las que se replique la versión. Por ejemplo, si
tiene dos imágenes y ambas se replican en tres regiones, entonces se le cambiará por seis discos
administrados según su tamaño. Para más información, consulte Precios de Managed Disks.
Cargos de salida de red para la replicación de la primera versión de la imagen desde la región de origen a las
regiones replicadas. Las réplicas subsiguientes se tratan dentro de la región, por lo que no habrá ningún
cargo adicional.
Actualización de recursos
Una vez creados, puede realizar algunos cambios en los recursos de la galería de imágenes. Estos se limitan a:
Galería de imágenes compartidas:
DESCRIPCIÓN
Definición de la imagen:
vCPU recomendadas:
Memoria recomendada
DESCRIPCIÓN
Fecha final del ciclo de vida
Versión de la imagen:
Recuento de réplicas regionales
Regiones de destino
Excluir de la versión más reciente
Compatibilidad con SDK

Los siguientes SDK admiten la creación de galerías de imágenes compartidas:
.NET
Java
Node.js
Python
Go
Plantillas
Puede crear recursos de galería de imágenes compartidas con plantillas. Hay varias plantillas de Inicio rápido de
Azure disponibles:
Creación de una galería de imágenes compartidas
Creación de una definición de imagen en una galería de imágenes compartidas
Creación de una versión de imagen en una galería de imágenes compartidas
Creación de una máquina virtual a partir de la versión de la imagen

¿Cómo puedo mostrar todos los recursos de Shared Image Gallery en las suscripciones?
¿Puedo mover una imagen existente a Shared Image Gallery?
¿Puedo crear una versión de la imagen a partir de un disco especializado?
¿Puedo mover el recurso de Shared Image Gallery a otra suscripción después de crearlo?
¿Puedo replicar las versiones de mis imágenes en nubes como Azure China 21Vianet, Azure Alemania o la
nube de Azure Government?
¿Puedo replicar las versiones de mis imágenes en las distintas suscripciones?
¿Puedo compartir versiones de imágenes entre los inquilinos de Azure AD?
¿Cuánto tardan en replicarse las versiones de las imágenes en las regiones de destino?
¿Cuál es la diferencia entre región de origen y región de destino?
¿Cómo especifico la región de origen al crear la versión de la imagen?
¿Cómo especifico el número de réplicas de la versión de la imagen que se crearán en cada región?
¿Puedo crear la instancia de Shared Image Gallery en una ubicación que no sea en la que se encuentran la
definición de la imagen y la versión de la imagen?
¿Cuánto cuesta usar Shared Image Gallery?
¿Qué versión de la API debo usar para crear Shared Image Gallery, así como la definición y la versión de la
imagen?
¿Qué versión de la API debo usar para crear una máquina virtual compartida o un conjunto de escalado de
máquinas virtuales a partir de la versión de la imagen?
¿Cómo puedo mostrar todos los recursos de la galería de imágenes compartidas en las suscripciones?
Para enumerar todos los recursos de Shared Image Gallery en las suscripciones a las que tiene acceso en Azure
Portal, siga estos pasos:
1. Abra Azure Portal.
2. Vaya a Todos los recursos.
3. Seleccione todas las suscripciones en las que quiera enumerar todos los recursos.
4. Busque los recursos de tipo Galería privada.
Para ver las definiciones de imagen y las versiones de imagen, debe seleccionar también Mostrar tipos
ocultos.
Para enumerar todos los recursos de la galería de imágenes compartidas mediante las suscripciones para
las que tiene permiso, use el comando siguiente en la CLI de Azure:
az account list -otsv --query "[].id" | xargs -n 1 az sig list --subscription
¿Puedo mover una imagen existente a la galería de imágenes compartidas?

Sí. Hay tres escenarios basados en los tipos de imagen que pueda tener.
Escenario 1: Si tiene una imagen administrada, puede crear una definición de la imagen y versión de la imagen a
partir de ella.
Escenario 2: Si tiene una imagen no administrada, puede crear una imagen administrada a partir de ella y, luego,
crear una definición de la imagen y una versión de la imagen a partir de ella.
Escenario 3: Si tiene un VHD en el sistema de archivos local, deberá cargar el VHD en una imagen administrada
y, luego, crear una definición de la imagen y una versión de la imagen a partir de ella.
Si el VHD es de una VM Windows, consulte Carga de un VHD.
Si el VHD es para una VM Linux, consulte Cargar un disco duro virtual.
¿Puedo crear una versión de la imagen desde un disco especializado?
Sí, la compatibilidad con discos especializados como imágenes está en versión preliminar. Solo puede crear una
máquina virtual a partir de una imagen especializada mediante el portal (Windows o Linux) y la API. No hay
compatibilidad con PowerShell para la versión preliminar.
¿Puedo mover el recurso de Shared Image Gallery a otra suscripción después de crearlo?
No, no puede mover el recurso de la galería de imágenes compartidas a otra suscripción. Sin embargo, podrá
replicar las versiones de la imagen en la galería a otras regiones según sea necesario.
¿Puedo replicar las versiones de mis imágenes en nubes como Azure China 21Vianet, Azure Alemania o la nube
de Azure Government?
No, no puede replicar las versiones de la imagen en las nubes.
¿Puedo replicar las versiones de mis imágenes entre suscripciones?
No, puede replicar las versiones de la imagen en varias regiones de una suscripción y usarla en otras
suscripciones a través de RBAC.
¿Puedo compartir versiones de imágenes entre los inquilinos de Azure AD?
Sí, puede utilizar RBAC para compartirlo con las personas entre los inquilinos. Pero, para compartir a escala,
consulte "Uso compartido de imágenes de la galería entre inquilinos de Azure" con PowerShell o CLI.
¿Cuánto tarda la replicación de versiones de imágenes en las regiones de destino?
El tiempo de replicación de la versión de una imagen depende totalmente del tamaño de la imagen y del número
de regiones en las que se va a replicar. Sin embargo, como práctica recomendada para obtener los mejores
resultados, se recomienda mantener una imagen pequeña y las regiones de origen y de destino cerca. Puede
comprobar el estado de la replicación mediante la marca -ReplicationStatus.
¿Cuál es la diferencia entre la región de origen y la región de destino?
La región de origen es la región en la que se creará la versión de la imagen, y las regiones de destino son las
regiones donde se almacenará una copia de la versión de la imagen. Para cada versión de una imagen, solo
puede tener una región de origen. Además, asegúrese de pasar la ubicación de la región de origen como una de
las regiones de destino cuando cree una versión de la imagen.
¿Cómo puedo especificar la región de origen al crear la versión de la imagen?
Al crear una versión de la imagen, puede usar la etiqueta --location en la CLI y la etiqueta -Location en
PowerShell para especificar la región de origen. Asegúrese de que la imagen administrada que usa como
imagen de base para crear la versión de la imagen esté en la misma ubicación que la ubicación en la que va a
crear la versión de la imagen. Además, asegúrese de pasar la ubicación de la región de origen como una de las
regiones de destino cuando cree una versión de la imagen.
¿Cómo puedo especificar el número de réplicas de la versión de la imagen que se creará en cada región?
Hay dos maneras de especificar el número de réplicas de la versión de la imagen que se creará en cada región:
1. El recuento de réplicas regionales que especifica el número de réplicas que desea crear para cada región.
2. El recuento de réplicas comunes que sea el recuento predeterminado por región en caso de que no se
especifique el recuento de réplicas regionales.
Para especificar el recuento de réplicas regionales, pase la ubicación junto con el número de réplicas que quiere
crear en esa región: "Centro-sur de EE. UU. = 2".
Si el recuento de réplicas regionales no se especifica con cada ubicación, el número predeterminado de réplicas
será el recuento de réplicas comunes que especificó.
Para especificar el recuento de réplicas comunes en la CLI, use el argumento --replica-count en el comando
az sig image-version create .
¿Puedo crear la instancia de Shared Image Gallery en una ubicación que no sea en la que se encuentran la
definición de la imagen y la versión de la imagen?
Sí, es posible. Pero como práctica recomendada, le animamos a mantener el grupo de recursos, la galería de
imágenes compartidas, la definición de la imagen y la versión de la imagen en la misma ubicación.
¿Cuáles son los cargos por uso de la galería de imágenes compartidas?
No hay ningún cargo por usar el servicio de la galería de imágenes compartidas, excepto los cargos de
almacenamiento de las versiones de las imágenes y los cargos de salida de red para la replicación de las
versiones de las imágenes de la región de origen a las regiones de destino.
¿Qué versión de la API debo usar para crear Shared Image Gallery, así como la definición y la versión de la
imagen?
Para trabajar con galerías de imágenes compartidas, definiciones de imágenes y versiones de imágenes, se
recomienda usar la API versión 2018-06-01. El almacenamiento con redundancia de zona (ZRS ) requiere la
versión de 2019-03-01 o posterior.
¿Qué versión de la API debo usar para crear una máquina virtual compartida o un conjunto de escalado de
máquinas virtuales a partir de la versión de la imagen?
Para implementaciones de VM y conjuntos de escalado de máquinas virtuales que usan una versión de la
imagen, se recomienda usar la API versión 2018-04-01 o posterior.
Pasos siguientes
Aprenda a implementar imágenes compartidas con Azure PowerShell.
con Azure PowerShell
Una galería de imágenes compartidas simplifica el uso compartido de imágenes personalizadas en toda una
organización. Las imágenes personalizadas son como las imágenes de Marketplace, pero las puede crear usted
mismo. Las imágenes personalizadas se pueden usar para realizar tareas de implementación de arranque, como la
carga previa de aplicaciones, configuraciones de aplicaciones y otras configuraciones del sistema operativo.
La Galería de imágenes compartidas le permite compartir sus imágenes de máquina virtual personalizadas con
otros usuarios de su organización, ya sea dentro o entre regiones, dentro de un inquilino de AAD. Elija las
imágenes que desea compartir, qué regiones desea que estén disponibles en ellas y con quién desea compartirlas.
Puede crear varias galerías que le permitirán agrupar lógicamente las imágenes compartidas.
La galería es un recurso de nivel superior que proporciona control de acceso basado en roles (RBAC ). Las
imágenes pueden tener varias versiones y se puede optar por replicar cada versión de la imagen en un conjunto
diferente de regiones de Azure. La galería solo funciona con imágenes administradas.
La característica de galería de imágenes compartidas tiene varios tipos de recursos. En este artículo, usaremos o
crearemos los siguientes elementos:
Imagen administrada Se trata de una imagen básica que se puede usar por sí sola o
para crear una versión de imagen de una galería de
imágenes. Las imágenes administradas se crean desde
máquinas virtuales generalizadas. Una imagen administrada
es un tipo de VHD especial que se puede usar para crear
varias máquinas virtuales y que ahora se puede usar para
crear versiones de imágenes compartidas.
Galería de imágenes Al igual que Azure Marketplace, una galería de imágenes es

un repositorio para administrar y compartir imágenes, pero
usted puede controlar quién tiene acceso.

información sobre la imagen y los requisitos para usarla
internamente. Esto incluye si la imagen es Windows o Linux,
notas de la versión y los requisitos de memoria mínima y
máxima. Es una definición de un tipo de imagen.
que una imagen administrada, cuando se usa una versión de
la imagen para crear una VM, la versión de la imagen se usa
para crear nuevos discos para la VM. Las versiones de las
Por cada 20 máquinas virtuales que cree simultáneamente, le recomendamos que conserve una réplica. Por
ejemplo, si va a crear 120 máquinas virtuales simultáneamente mediante la misma imagen en una región, se
recomienda conservar al menos seis réplicas de la imagen. Para más información, consulte Escalado.
Antes de empezar
Para completar el ejemplo de este artículo, debe tener una imagen administrada existente. Puede seguir Tutorial:
Creación de una imagen personalizada de una máquina virtual de Azure con Azure PowerShell para crear una si
es necesario. Si la imagen administrada contiene un disco de datos, el tamaño del disco de datos no puede ser
mayor de 1 TB.
Al trabajar en este artículo, reemplace los nombres de grupo de recursos y máquina virtual cuando proceda.

explorador. Seleccione Copiar para copiar los bloques de código, péguelos en Cloud Shell y, luego, presione Entrar
para ejecutarlos.
Obtener la imagen administrada

Puede ver una lista de imágenes disponibles en un grupo de recursos con Get-AzImage. Una vez que sepa el
nombre de la imagen y en qué grupo de recursos está, puede usar Get-AzImage nuevamente para obtener el
objeto de imagen y almacenarlo en una variable para usarlo más adelante. En este ejemplo se obtiene una imagen
denominada myImage desde el grupo de recursos "myResourceGroup" y se asigna a la variable $managedImage.
$managedImage = Get-AzImage `
Creación de una galería de imágenes

Una galería de imágenes es el recurso principal que se usa para habilitar el uso compartido de imágenes. Los
caracteres permitidos para el nombre de la Galería son letras mayúsculas o minúsculas, números y puntos. El
nombre de la galería no puede contener guiones. Los nombres de las galerías deben ser únicos dentro de su
suscripción.
Cree una galería de imágenes con New -AzGallery. En el ejemplo siguiente se crea una galería denominada
myGallery en el grupo de recursos myGalleryRG.
$resourceGroup = New-AzResourceGroup `
-Name 'myGalleryRG' `
-Location 'West Central US'
$gallery = New-AzGallery `
-GalleryName 'myGallery' `
-ResourceGroupName $resourceGroup.ResourceGroupName `
-Location $resourceGroup.Location `
-Description 'Shared Image Gallery for my organization'
Creación de la definición de una imagen

Las definiciones de imagen crean una agrupación lógica de imágenes. Estas se usan para administrar la
información sobre las versiones de la imagen que se crean dentro de ellas. Los nombres de las definiciones de
imagen pueden estar formados por letras mayúsculas o minúsculas, números, puntos y guiones. Para más
información sobre los valores que se pueden especificar para una definición de imagen, consulte Definiciones de
imagen.
Cree la definición de imagen mediante New -AzGalleryImageDefinition. En este ejemplo, la imagen de la galería se
denomina myGalleryImage.
$galleryImage = New-AzGalleryImageDefinition `
-GalleryName $gallery.Name `
-Location $gallery.Location `
-Name 'myImageDefinition' `
-OsState generalized `
-OsType Windows `
-Publisher 'myPublisher' `
-Offer 'myOffer' `
-Sku 'mySKU'
Creación de la versión de una imagen

Cree una versión de la imagen a partir de una imagen administrada mediante New -AzGalleryImageVersion.
Los caracteres permitidos para la versión de una imagen son números y puntos. Los números deben estar dentro
del rango de un entero de 32 bits. Formato: VersiónPrincipal.VersiónSecundaria.Revisión.
En este ejemplo, la versión de imagen es 1.0.0 y se replica en los centros de datos Centro -oeste de EE. UU. y
Centro -sur de EE. UU. Al elegir las regiones de destino de la replicación, recuerde que también debe incluir la
región de origen como destino de la replicación.
$region1 = @{Name='South Central US';ReplicaCount=1}

$region2 = @{Name='West Central US';ReplicaCount=2}
$targetRegions = @($region1,$region2)
$job = $imageVersion = New-AzGalleryImageVersion `
-GalleryImageDefinitionName $galleryImage.Name `
-GalleryImageVersionName '1.0.0' `
-Location $resourceGroup.Location `
-TargetRegion $targetRegions `
-Source $managedImage.Id.ToString() `
-PublishingProfileEndOfLifeDate '2020-01-01' `
-asJob
Puede tardar un rato en replicar la imagen en todas las regiones de destino, por lo que creamos un trabajo para
que pueda hacer un seguimiento del progreso. Para ver el progreso del trabajo, escriba $job.State .
$job.State
NOTE
Deberá esperar a que la versión de la imagen termine de compilarse y replicarse por completo antes de poder usar la misma
imagen administrada para crear otra versión de la imagen.
También puede almacenar la versión de la imagen en almacenamiento con redundancia de zona si agrega
-StorageAccountType Standard_ZRS al crear la versión de la imagen.
Uso compartido de la galería

Se recomienda compartir el acceso en el nivel de la galería de imágenes. Use una dirección de correo electrónico y
el cmdlet Get-AzADUser para obtener el identificador de objeto del usuario y, después, utilice New -
AzRoleAssignment para concederle acceso a la galería. Reemplace el correo electrónico
alinne_montes@contoso.com de este ejemplo por su propia información.
# Get the object ID for the user

$user = Get-AzADUser -StartsWith alinne_montes@contoso.com
# Grant access to the user for our gallery
New-AzRoleAssignment `
-ObjectId $user.Id `
-RoleDefinitionName Reader `
-ResourceName $gallery.Name `
-ResourceType Microsoft.Compute/galleries `
-ResourceGroupName $resourceGroup.ResourceGroupName
Creación de máquinas virtuales a partir de una imagen

Una vez que la versión de la imagen se completa, puede crear una o varias VM nuevas. Mediante el uso del cmdlet
New -AzVM.
Este ejemplo crea una máquina virtual llamada myVMfromImage en myResourceGroup en el centro de datos
Centro y Sur de EE. UU.
$location = "South Central US"
$vmName = "myVMfromImage"


# Network pieces
# Create a virtual machine configuration using $imageVersion.Id to specify the shared image
$vmConfig = New-AzVMConfig -VMName $vmName -VMSize Standard_D1_v2 | `
Set-AzVMSourceImage -Id $imageVersion.Id | `

Administración de imágenes compartidas

Estos son algunos ejemplos de tareas comunes de administración y cómo realizarlas mediante PowerShell.
Enumere todas las galerías por nombre.
$galleries = Get-AzResource -ResourceType Microsoft.Compute/galleries
$galleries.Name
Enumere todas las definiciones de una imagen por nombre.
$imageDefinitions = Get-AzResource -ResourceType Microsoft.Compute/galleries/images

$imageDefinitions.Name
Enumere todas las versiones de una imagen por nombre.
$imageVersions = Get-AzResource -ResourceType Microsoft.Compute/galleries/images/versions

$imageVersions.Name
Elimine la versión de una imagen. En este ejemplo se elimina la versión de la imagen denominada 1.0.0.
Remove-AzGalleryImageVersion `
-GalleryImageDefinitionName myImageDefinition `
-GalleryName myGallery `
-Name 1.0.0 `
-ResourceGroupName myGalleryRG
Existen algunas limitaciones en lo que se puede actualizar. Se pueden actualizar los siguientes elementos:
DESCRIPCIÓN
vCPU recomendadas:
Memoria recomendada
DESCRIPCIÓN
Regiones de destino
Exclusión de la versión más reciente
Si planea agregar regiones de réplica, no elimine la imagen administrada de origen. La imagen administrada de
origen es necesaria para replicar la versión de la imagen a regiones adicionales.
Para actualizar la descripción de una galería, use Update-AzGallery.
Update-AzGallery `
-Name $gallery.Name `
-ResourceGroupName $resourceGroup.Name
En este ejemplo se muestra cómo usar Update-AzGalleryImageDefinition para actualizar la fecha de vencimiento
de nuestra definición de imagen.
Update-AzGalleryImageDefinition `
-Name $galleryImage.Name `
-ResourceGroupName $resourceGroup.Name `
-EndOfLifeDate 01/01/2030
En este ejemplo se muestra cómo usar Update-AzGalleryImageVersion para impedir que esta versión de imagen
se use como la imagen más reciente.
Update-AzGalleryImageVersion `
-GalleryImageDefinitionName $galleryImage.Name `
-Name $galleryVersion.Name `
-ResourceGroupName $resourceGroup.Name `
-PublishingProfileExcludeFromLatest
Al eliminar los recursos, debe comenzar por el último elemento de los recursos anidados: la versión de imagen.
Cuando se hayan eliminado las versiones, puede eliminar la definición de imagen. No se puede eliminar la galería
hasta que se hayan eliminado todos los recursos por debajo de ella.
$gallery = "myGallery"
$imageDefinition = "myImageDefinition"
$imageVersion = "myImageVersion"
Remove-AzGalleryImageVersion `
-GalleryImageDefinitionName $imageDefinition `
-GalleryName $gallery `
-Name $imageVersion `
Remove-AzGalleryImageDefinition `
-GalleryName $gallery `
-GalleryImageDefinitionName $imageDefinition
Remove-AzGallery `
-Name $gallery `
Remove-AzResourceGroup -Name $resourceGroup
Pasos siguientes
Azure Image Builder (versión preliminar) puede ayudar a automatizar la creación de versiones de la imagen,
incluso se puede usar para actualizar y crear una nueva versión de la imagen a partir de una versión de imagen
existente.
Puede crear también recursos de galería de imágenes compartidas con plantillas. Hay varias plantillas de Inicio
rápido de Azure disponibles:
Para más información sobre las galerías de imágenes compartidas, consulte la Introducción. Si encuentra
problemas, consulte Solución de problemas de galerías de imágenes compartidas.
mediante Azure Portal
mismo. Las imágenes personalizadas se pueden usar para realizar tareas de implementación de arranque, como la
carga previa de aplicaciones, configuraciones de aplicaciones y otras configuraciones del sistema operativo.
La Galería de imágenes compartidas le permite compartir sus imágenes de máquina virtual personalizadas con
otros usuarios de su organización, ya sea dentro o entre regiones, dentro de un inquilino de AAD. Elija las
imágenes que desea compartir, qué regiones desea que estén disponibles en ellas y con quién desea compartirlas.
Puede crear varias galerías que le permitirán agrupar lógicamente las imágenes compartidas.
La galería es un recurso de nivel superior que proporciona control de acceso basado en roles (RBAC ). Las
imágenes pueden tener varias versiones y se puede optar por replicar cada versión de la imagen en un conjunto
diferente de regiones de Azure. La galería solo funciona con imágenes administradas.
Imagen administrada Una imagen básica que se puede usar por sí sola o para crear
una versión de imagen de una galería de imágenes. Las
imágenes administradas se crean a partir de máquinas
virtuales generalizadas. Una imagen administrada es un tipo
de VHD especial que se puede usar para crear varias máquinas
virtuales y que ahora se puede usar para crear versiones de
imágenes compartidas.
Instantánea Una copia de un disco duro virtual que se puede usar para
crear una versión de imagen. Las instantáneas pueden
tomarse de una máquina virtual especializada (una que no se
ha generalizado) y, luego, usarse por sí sola o con instantáneas
de discos de datos para crear una versión de imagen
especializada.


información sobre la imagen y los requisitos para usarla en la
organización. Puede incluir información como si la imagen es
generalizada o especializada, el sistema operativo, los
requisitos de memoria mínima y máxima, y las notas de la
versión. Es una definición de un tipo de imagen.
que una imagen administrada, cuando se usa una versión de
la imagen para crear una VM, la versión de la imagen se usa
para crear nuevos discos para la VM. Las versiones de las
IMPORTANT
Las imágenes especializadas están actualmente en versión preliminar pública. Esta versión preliminar se ofrece sin Acuerdo de
Nivel de Servicio y no se recomienda para cargas de trabajo de producción. Es posible que algunas características no sean
Limitaciones conocidas de la versión preliminar las máquinas virtuales solo se pueden crear a partir de imágenes
especializadas mediante el portal o la API. No es compatible con la CLI ni con PowerShell para la versión preliminar.
Antes de empezar
Para completar el ejemplo de este artículo, debe tener una imagen administrada existente de una máquina virtual
generalizada o una instantánea de una máquina virtual especializada. Puede seguir Tutorial: Cree una imagen
personalizada de una máquina virtual de Azure con Azure PowerShell para crear una imagen administrada o Cree
una instantánea para una máquina virtual especializada. En el caso de las instantáneas e imágenes administradas,
el tamaño del disco de datos no puede ser superior a 1 TB.
Al trabajar en este artículo, reemplace los nombres de grupo de recursos y máquina virtual cuando proceda.

NOTE
Si se ha registrado para usar galerías de imágenes compartidas durante la versión preliminar, puede que deba volver a
registrar el proveedor Microsoft.Compute . Abra Cloud Shell y escriba: az provider register -n Microsoft.Compute .

caracteres permitidos para el nombre de la Galería son letras mayúsculas o minúsculas, números y puntos. El
nombre de la galería no puede contener guiones. Los nombres de las galerías deben ser únicos dentro de su
suscripción.
En el ejemplo siguiente se crea una galería denominada myGallery en el grupo de recursos myGalleryRG.
1. Haga clic en Crear un recurso en la esquina superior izquierda de Azure Portal.
2. Use el tipo Galería de imágenes compartidas en el cuadro de búsqueda y seleccione Galería de imágenes
compartidas en los resultados.
3. En la página Galería de imágenes compartidas, haga clic en Crear.
4. Seleccione la suscripción correcta.
5. En Grupo de recursos, seleccione Crear nuevo y escriba myGalleryRG como nombre.
6. En Nombre, escriba myGallery como nombre de la galería.
7. En Región, deje el valor predeterminado.
8. Puede escribir una descripción corta de la galería, como Mi galería de imágenes para prueba. Después, haga
clic en Revisar y crear.
9. Una vez pasada la validación, seleccione Crear.
10. Cuando la implementación finalice, seleccione Ir al recurso.

Las definiciones de imagen crean una agrupación lógica de imágenes. Estas se usan para administrar la
información sobre las versiones de la imagen que se crean dentro de ellas. Los nombres de las definiciones de
imagen pueden estar formados por letras mayúsculas o minúsculas, números, puntos y guiones. Para más
información sobre los valores que se pueden especificar para una definición de imagen, consulte Definiciones de
imagen.
Cree la definición de imagen de la galería dentro de la galería. En este ejemplo, la imagen de la galería se
denomina myImageDefinition.
1. En la página de la nueva galería de imágenes, seleccione Add a new image definition (Agregar una nueva
definición de imagen) en la parte superior de la página.
2. En Nombre de definición de la imagen, escriba myImageDefinition.
3. En Sistema operativo, seleccione la opción correcta en función de la VM de origen.
4. En Generación de VM, seleccione la opción en función de la VM de origen. En la mayoría de los casos, será
Gen 1. Para obtener más información, consulte Compatibilidad para máquinas virtuales de generación 2 en
Azure.
5. En Estado del sistema operativo, seleccione la opción en función de la VM de origen. Para más información,
consulte Generalizada o Especializada.
6. En Publicador, escriba myPublisher.
7. En Oferta, escriba myOffer.
8. En SKU, escriba mySKU.
9. Cuando termine, seleccione Revisar y crear.
10. Después de que la definición de imagen pasa la validación, seleccione Crear.

Cree una versión de la imagen a partir de una imagen administrada. En este ejemplo, la versión de imagen es 1.0.0
y se replica en los centros de datos Centro -oeste de EE. UU. y Centro -sur de EE. UU. Al elegir las regiones de
destino de la replicación, recuerde que también debe incluir la región de origen como destino de la replicación.
del rango de un entero de 32 bits. Formato: VersiónPrincipal.VersiónSecundaria.Revisión.
Los pasos para crear una versión de la imagen son ligeramente diferentes, en función de si el origen es una
imagen generalizada o una instantánea de una VM especializada.
Opción: Generalizada
1. En la página de la definición de imagen, seleccione Agregar versión en la parte superior de la página.
2. En Región, seleccione la región donde se almacena la imagen administrada. Las versiones de imagen deben
crearse en la misma región que la imagen administrada a partir de la que se crean.
3. En Nombre, escriba 1.0.0. El nombre de la versión de la imagen debe seguir el formato principal.
secundaria.revisión con números enteros.
4. En Imagen de origen, seleccione la imagen administrada de origen en la lista desplegable.
5. En Excluir de las últimas, deje el valor predeterminado de No.
6. En End of life date (Fecha del final de la duración), seleccione una fecha del calendario que sea un par de
meses en el futuro.
7. En Replicación, deje Número de réplicas predeterminado en 1. Como debe replicar en la región de origen,
deje la primera réplica como predeterminada y, luego, elija una segunda región de réplica, en este caso Este de
EE. UU. .
8. Cuando haya terminado, seleccione Revisar y crear. Azure validará la configuración.
9. Una vez que la versión de la imagen supere la validación, seleccione Crear.
La imagen puede tardar un rato en replicarse en todas las regiones de destino.
Opción: Especializada
1. En la página de la definición de imagen, seleccione Agregar versión en la parte superior de la página.
2. En Región, seleccione la región en la que se almacenará la instantánea. Las versiones de imagen deben crearse
en la misma región que el origen a partir del que se crean.
3. En Nombre, escriba 1.0.0. El nombre de la versión de la imagen debe seguir el formato principal.
secundaria.revisión con números enteros.
4. En Instantánea del disco del sistema operativo, seleccione la instantánea de la VM de origen en la lista
desplegable. Si la VM de origen tenía un disco de datos que quiere incluir, seleccione el número de
LUNcorrecto de la lista desplegable y luego seleccione la instantánea del disco de datos en Instantánea del
disco de datos.
5. En Excluir de las últimas, deje el valor predeterminado de No.
6. En End of life date (Fecha del final de la duración), seleccione una fecha del calendario que sea un par de
meses en el futuro.
7. En Replicación, deje Número de réplicas predeterminado en 1. Como debe replicar en la región de origen,
deje la primera réplica como predeterminada y, luego, elija una segunda región de réplica, en este caso Este de
EE. UU. .
8. Cuando haya terminado, seleccione Revisar y crear. Azure validará la configuración.
9. Una vez que la versión de la imagen supere la validación, seleccione Crear.

Se recomienda compartir el acceso en el nivel de la galería de imágenes. Los siguientes pasos le guían por el uso
compartido de la galería que acaba de crear.
2. En el menú de la izquierda, seleccione Grupos de recursos.
3. En la lista de grupos de recursos, seleccione myGalleryRG. Se abrirá la hoja del grupo de recursos.
4. En el menú de la izquierda de la página myGalleryRG, seleccione Control de acceso (IAM ) .
5. En Agregar una asignación de roles, seleccione Agregar. Se abre el panel Agregar una asignación de
roles.
6. En Rol, seleccione Lector.
7. En Asignar acceso a, deje el valor predeterminado de Usuario, grupo o entidad de servicio de Azure AD.
8. En Seleccionar, escriba la dirección de correo electrónico de la persona a la que quiere invitar.
9. Si el usuario está fuera de su organización, verá el mensaje This user will be sent an email that enables
them to collaborate with Microsoft (A este usuario se le enviará un correo electrónico que le permite
colaborar con Microsoft). Seleccione el usuario con la dirección de correo electrónico y, luego, haga clic en
Guardar.
Si el usuario está fuera de su organización, recibirá una invitación por correo electrónico para unirse a ella. Debe
aceptarla para ver la galería y todas las definiciones y versiones de imágenes de su lista de recursos.

Ahora puede crear una o varias máquinas virtuales nuevas. En este ejemplo se crea una máquina virtual
denominada myVM, en el myResourceGroup, en el centro de recursos del Este de EE. UU.
1. Vaya a la definición de la imagen. Puede usar el filtro de recursos para mostrar todas las definiciones de imagen
disponibles.
2. En la página de la definición de la imagen, seleccione Crear máquina virtual en el menú de la parte superior
de la página.
3. En Grupo de recursos, seleccione Crear nuevo y escriba myResourceGroup como nombre.
4. En Nombre de máquina virtual, escriba myVM.
5. En Región, seleccione Este de EE. UU. .
6. En Opciones de disponibilidad, deje el valor predeterminado No se requiere redundancia de la
infraestructura.
7. El valor de Imagen se completa automáticamente con la versión de imagen latest si se inició desde la página
para la definición de imagen.
8. En Tamaño, elija un tamaño de máquina virtual en la lista de tamaños disponibles y, después, elija
Seleccionar.
9. En Cuenta de administrador, si la imagen estaba generalizada, debe proporcionar un nombre de usuario,
como azureuser y una contraseña. La contraseña debe tener al menos 12 caracteres de largo y cumplir con los
requisitos de complejidad definidos. Si la imagen estaba especializada, los campos de nombre de usuario y
contraseña se atenuarán porque se usan el nombre de usuario y la contraseña de la máquina virtual de origen.
10. Si quiere permitir el acceso remoto a la VM, en Puertos de entrada públicos, elija Permitir puertos
seleccionados y, a continuación, seleccione SSH (3389) en la lista desplegable. Si no desea permitir el acceso
remoto a la máquina virtual, deje Ninguno seleccionado en Puertos de entrada públicos.
11. Cuando haya terminado, seleccione el botón Revisar y crear situado en la parte inferior de la página.
12. Una vez que la máquina virtual haya superado la validación, seleccione Crear en la parte inferior de la página
para iniciar la implementación.
relacionados. Para ello, seleccione el grupo de recursos de la máquina virtual, seleccione Eliminar y luego
confirme el nombre del grupo de recursos para eliminar.
Si desea eliminar recursos individuales, deberá eliminarlos en el orden inverso. Por ejemplo, para eliminar una
definición de la imagen, deberá eliminar todas las versiones de la imagen creadas a partir de esa imagen.
Pasos siguientes
Puede crear también recursos de galería de imágenes compartidas con plantillas. Hay varias plantillas de Inicio
rápido de Azure disponibles:
Para más información sobre las galerías de imágenes compartidas, consulte la Introducción. Si encuentra
problemas, consulte Solución de problemas de galerías de imágenes compartidas.
Creación de una galería de imágenes compartidas con
la CLI de Azure
mismo. Las imágenes personalizadas pueden usarse para configuraciones de arranque como la carga previa de
aplicaciones, configuraciones de aplicaciones y otras configuraciones del sistema operativo.
La Galería de imágenes compartidas le permite compartir sus imágenes de máquina virtual personalizadas con otros
usuarios de su organización, ya sea dentro o entre regiones, dentro de un inquilino de AAD. Elija las imágenes que
desea compartir, qué regiones desea que estén disponibles en ellas y con quién desea compartirlas. Puede crear
varias galerías que le permitirán agrupar lógicamente las imágenes compartidas.
La galería es un recurso de nivel superior que proporciona control de acceso basado en roles (RBAC ). Las imágenes
pueden tener varias versiones y se puede optar por replicar cada versión de la imagen en un conjunto diferente de
regiones de Azure. La galería solo funciona con imágenes administradas.
Imagen administrada Se trata de una imagen básica que se puede usar por sí sola o
para crear una versión de imagen de una galería de imágenes.
Las imágenes administradas se crean desde máquinas virtuales
generalizadas. Una imagen administrada es un tipo de VHD
especial que se puede usar para crear varias máquinas virtuales
y que ahora se puede usar para crear versiones de imágenes
compartidas.


información sobre la imagen y los requisitos para usarla
internamente. Esto incluye si la imagen es Windows o Linux,
notas de la versión y los requisitos de memoria mínima y
máxima. Es una definición de un tipo de imagen.
Versión de la imagen Una versión de la imagen es lo que se usa para crear una VM
cuando se usa una galería. Puede tener varias versiones de una
imagen según sea necesario para su entorno. Al igual que una
imagen administrada, cuando se usa una versión de la imagen
para crear una VM, la versión de la imagen se usa para crear
nuevos discos para la VM. Las versiones de las imágenes
pueden usarse varias veces.
Antes de empezar
Para completar el ejemplo de este artículo, debe tener una imagen administrada existente de una VM generalizada.
Para más información, consulte Tutorial: Creación de una imagen personalizada de una máquina virtual de Azure con
la CLI de Azure. Si la imagen administrada contiene un disco de datos, el tamaño de este no puede ser mayor de 1 TB.
Para abrir Cloud Shell, seleccione Pruébelo en la esquina superior derecha de un bloque de código. También puede ir
a https://shell.azure.com/bash para iniciar Cloud Shell en una pestaña independiente del explorador. Seleccione
Copiar para copiar los bloques de código, péguelos en Cloud Shell y, luego, presione Entrar para ejecutarlos.
Para instalar y usar la CLI de forma local, consulte Instalación de la CLI de Azure.

caracteres permitidos para el nombre de la Galería son letras mayúsculas o minúsculas, números y puntos. El nombre
de la galería no puede contener guiones. Los nombres de las galerías deben ser únicos dentro de su suscripción.
Cree una galería de imágenes mediante az sig az create. En el ejemplo siguiente se crea una galería denominada
myGallery en myGalleryRG.
az group create --name myGalleryRG --location WestCentralUS

az sig create --resource-group myGalleryRG --gallery-name myGallery

Las definiciones de imagen crean una agrupación lógica de imágenes. Estas se usan para administrar la información
sobre las versiones de la imagen que se crean dentro de ellas. Los nombres de las definiciones de imagen pueden
estar formados por letras mayúsculas o minúsculas, números, puntos y guiones. Para más información sobre los
valores que se pueden especificar para una definición de imagen, consulte Definiciones de imagen.
Cree la definición de una imagen inicial en la galería mediante az sig image-definition create.
az sig image-definition create \

--resource-group myGalleryRG \
--gallery-name myGallery \
--gallery-image-definition myImageDefinition \
--publisher myPublisher \
--offer myOffer \
--sku 16.04-LTS \
--os-type Linux

Cree versiones de la imagen según sea necesario con az image gallery create-image-version. Deberá pasar el
identificador de la imagen administrada que se usará como base para crear la versión de la imagen. Puede usar az
image list para obtener información sobre las imágenes que se encuentran en un grupo de recursos.
Los caracteres permitidos para la versión de una imagen son números y puntos. Los números deben estar dentro del
rango de un entero de 32 bits. Formato: VersiónPrincipal.VersiónSecundaria.Revisión.
En este ejemplo, es la versión de la imagen es la 1.0.0 y vamos a crear dos réplicas en la región Centro -oeste de EE.
UU. , una réplica en la región Centro -sur de EE. UU. y una réplica en la región Este de EE. UU. 2 región mediante
almacenamiento con redundancia de zona.
az sig image-version create \
--gallery-image-version 1.0.0 \
--target-regions "WestCentralUS" "SouthCentralUS=1" "EastUS2=1=Standard_ZRS" \
--replica-count 2 \
--managed-image "/subscriptions/<subscription
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/images/myImage"
NOTE
También puede almacenar todas las réplicas de la versión de la imagen en almacenamiento con redundancia de zona si agrega
--storage-account-type standard_zrs al crear la versión de la imagen.

Se recomienda que el uso compartido con otros usuarios se realice en el nivel de la galería. Para obtener el
identificador de objeto de la galería, use az sig show.
az sig show \
--query id
Use el identificador de objeto como ámbito, junto con una dirección de correo electrónico y az role assignment create
para dar a un usuario acceso a la galería de imágenes compartidas.
az role assignment create --role "Reader" --assignee <email address> --scope <gallery ID>
Crear una VM
Cree una máquina virtual a partir de la versión de imagen más reciente mediante az vm create.
az vm create\
--name myVM \
--image "/subscriptions/subscription ID where the gallery is
located>/resourceGroups/myGalleryRG/providers/Microsoft.Compute/galleries/myGallery/images/myImageDefinition" \
--generate-ssh-keys
También puede usar una versión específica con el identificador de la versión de imagen del parámetro --image . Por
ejemplo, para usar la versión de imagen 1.0.0, escriba:
--image "/subscriptions/<subscription ID where the gallery is
located>/resourceGroups/myGalleryRG/providers/Microsoft.Compute/galleries/myGallery/images/myImageDefinition/versions/1.0.0"
.
Uso de RBAC para compartir imágenes

Puede compartir imágenes entre suscripciones mediante el Control de acceso basado en roles (RBAC ). Cualquier
usuario que tenga permisos de lectura para una versión de la imagen, incluso entre suscripciones, será capaz de
implementar una máquina virtual con la versión de la imagen.
Para más información sobre cómo compartir recursos con RBAC, consulte Administración del acceso mediante RBAC
y la CLI de Azure.
Visualización de la información
Para obtener la ubicación, el estado y demás información sobre las galerías de imágenes disponibles, use az sig list.
az sig list -o table
Enumere las definiciones de las imágenes en una galería, incluida la información sobre el tipo de sistema operativo y
el estado, con az sig image-definition list.
az sig image-definition list --resource-group myGalleryRG --gallery-name myGallery -o table
Enumere las versiones de imágenes compartidas en una galería, con az sig image-version list.
az sig image-version list --resource-group myGalleryRG --gallery-name myGallery --gallery-image-definition

myImageDefinition -o table
Obtenga el identificador de una versión de imagen con az sig image-version show.
az sig image-version show \

--query "id"
Existen algunas limitaciones en lo que se puede actualizar. Se pueden actualizar los siguientes elementos:
DESCRIPCIÓN
vCPU recomendadas:
Memoria recomendada
DESCRIPCIÓN
Regiones de destino
Exclusión de la versión más reciente
Si planea agregar regiones de réplica, no elimine la imagen administrada de origen. La imagen administrada de
origen es necesaria para replicar la versión de la imagen a regiones adicionales.
Actualice la descripción de una galería con az sig update.
az sig update \
--set description="My updated description."
Actualice la descripción de una definición de imagen con az sig image-definition update.
az sig image-definition update \

--gallery-name myGallery\
--set description="My updated description."
Actualice una versión de imagen para agregar una región para replicar con az sig image-version update. Este cambio
tardará un poco, a medida que la imagen se replica en la nueva región.
az sig image-version update \

--add publishingProfile.targetRegions name=eastus
Eliminar recursos
Debe eliminar los recursos en orden inverso, eliminando primero la versión de imagen. Después de eliminar todas las
versiones de imagen, puede eliminar la definición de imagen. Después de eliminar todas las definiciones de imagen,
puede eliminar la galería.
Elimine una versión de imagen con az sig image-version delete.
az sig image-version delete \

--gallery-image-version 1.0.0
Elimine una definición de imagen con az sig image-definition delete.
az sig image-definition delete \

--gallery-image-definition myImageDefinition
Elimine una galería de imágenes mediante az sig delete.
az sig delete \
--gallery-name myGallery
Pasos siguientes
Azure Image Builder (versión preliminar)puede ayudar a automatizar la creación de la versión de imagen, incluso lo
puede usar para actualizar y crear una versión de imagen nueva a partir de una versión de imagen existente.
Puede crear también recursos de Shared Image Gallery con plantillas. Hay varias plantillas de Inicio rápido de Azure
disponibles:
Para más información sobre las galerías de imágenes compartidas, consulte la Introducción. Si encuentra problemas,
consulte Solución de problemas de galerías de imágenes compartidas.
Uso compartido de imágenes de la máquina virtual
de la galería entre inquilinos de Azure
Las galerías de imágenes compartidas le permiten compartir las imágenes mediante RBAC. Puede utilizar RBAC
para compartir imágenes dentro de su inquilino e incluso con personas de fuera de él. Para más información sobre
esta opción de uso compartido simple, consulte Compartir la galería.
Pero si quiere compartir las imágenes fuera de su inquilino de Azure, a escala, debe crear un registro de aplicación
para facilitar el uso compartido. Usar un registro de aplicación puede habilitar escenarios de uso compartidos más
complejos, como por ejemplo:
Administración de imágenes compartidas cuando una compañía adquiere otra y la infraestructura de Azure se
distribuye entre inquilinos independientes.
Los asociados de Azure administran la infraestructura de Azure en nombre de sus clientes. La personalización
de imágenes se realiza en el inquilino de los asociados, pero las implementaciones de infraestructura se
realizarán en el inquilino del cliente.
Creación del registro de aplicaciones

Cree un registro de aplicación que usarán ambos inquilinos para compartir los recursos de la galería de imágenes.
1. Abra Registros de aplicaciones (versión preliminar) en Azure Portal.
2. En el menú de la parte superior de la página, seleccione Nuevo registro.
3. En Nombre, escriba myGalleryApp.
4. En Tipos de cuenta admitidos, seleccione Cuentas en cualquier directorio organizativo y cuentas
Microsoft personales.
5. En URI de redirección, escriba https://www.microsoft.com y luego haga clic en Registrar. Una vez creado el
registro de aplicación, se abrirá la página de información general.
6. En la página de información general, copie el identificador de aplicación (cliente) y guárdelo para usarlo
más adelante.
7. Seleccione Certificados y secretos y luego seleccione Nuevo secreto de cliente.
8. En Descripción, escriba Shared image gallery cross-tenant app secret (Secreto de aplicación entre inquilinos
de la Galería de imágenes compartidas).
9. En Expires, deje el valor predeterminado de En 1 año y, después, seleccione Agregar.
10. Copie el valor del secreto y guárdelo en un lugar seguro. No podrá recuperarlo después de salir de la página.
Conceda permiso al registro de aplicación para usar la Galería de imágenes compartidas.
1. En Azure Portal, seleccione la Galería de imágenes compartidas que quiere compartir con otro inquilino.
2. Seleccione Control de acceso (IAM ) y en Agregar asignación de roles, seleccione Agregar.
3. En Rol, seleccione Lector.
4. En Asignar acceso a, déjelo como Usuario, grupo o entidad de servicio de Azure AD.
5. En Seleccionar, escriba myGalleryApp y haga clic sobre él cuando aparezca en la lista. Cuando finalice,
seleccione Guardar.
Conceder acceso a Inquilino 2

Conceda acceso a Inquilino 2 a la aplicación solicitando un inicio de sesión mediante un explorador. Reemplace
<Tenant2 ID> con el id. del inquilino con el que le gustaría compartir la galería de imágenes. Reemplace
<Application (client) ID> con el identificador de la aplicación del registro de aplicación que creó. Cuando haya
terminado de realizar los reemplazos, pegue la dirección URL en un explorador y siga las instrucciones de inicio de
sesión para iniciar sesión en Inquilino 2.
https://login.microsoftonline.com/<Tenant 2 ID>/oauth2/authorize?client_id=<Application (client)

ID>&response_type=code&redirect_uri=https%3A%2F%2Fwww.microsoft.com%2F
En Azure Portal, inicie sesión como Inquilino 2 y dé acceso de registro de aplicación al grupo de recursos donde
quiere crear la máquina virtual.
1. Seleccione el grupo de recursos, y luego haga clic en Control de acceso (IAM ) . En Agregar asignación de
roles, seleccione Agregar.
2. En Rol, escriba Colaborador.
3. En Asignar acceso a, déjelo como Usuario, grupo o entidad de servicio de Azure AD.
4. En Seleccionar, escriba myGalleryApp y luego haga clic sobre él cuando aparezca en la lista. Cuando finalice,
seleccione Guardar.
NOTE
IMPORTANT
No se puede usar el portal para implementar una VM desde una imagen en otro inquilino de Azure. Para crear una VM
desde una imagen que se comparte entre los inquilinos, debe usar la CLI de Azure o Powershell.
Creación de una máquina virtual con PowerShell

Inicie sesión en ambos inquilinos con el identificador de la aplicación, el secreto y el identificador del inquilino.
$applicationId = '<App ID>'

$secret = <Secret> | ConvertTo-SecureString -AsPlainText -Force
$tenant1 = "<Tenant 1 ID>"
$tenant2 = "<Tenant 2 ID>"
$cred = New-Object -TypeName PSCredential -ArgumentList $applicationId, $secret
Clear-AzContext
Connect-AzAccount -ServicePrincipal -Credential $cred -Tenant "<Tenant 1 ID>"
Connect-AzAccount -ServicePrincipal -Credential $cred -Tenant "<Tenant 2 ID>"
Cree la máquina virtual en el grupo de recursos que tenga permiso en el registro de la aplicación. Reemplace la
información del ejemplo por la suya.
$location = "South Central US"
$vmName = "myVMfromImage"
# Set a variable for the image version in Tenant 1 using the full image ID of the shared image version
$image = "/subscriptions/<Tenant 1 subscription>/resourceGroups/<Resource
group>/providers/Microsoft.Compute/galleries/<Gallery>/images/<Image definition>/versions/<version>"


# Networking pieces
# Create a virtual machine configuration using the $image variable to specify the shared image
$vmConfig = New-AzVMConfig -VMName $vmName -VMSize Standard_D1_v2 | `
Set-AzVMSourceImage -Id $image | `

Pasos siguientes
Puede crear también recursos de galería de imágenes compartidas con Azure Portal.
Solución de problemas de galerías de imágenes
compartidas
Si tiene problemas al realizar cualquier operación en galerías de imágenes compartidas, definiciones de imágenes
y versiones de imágenes, vuelva a ejecutar el comando con errores en modo de depuración. El modo de
depuración se activa al pasar el conmutador -debug con la CLI y el conmutador -debug con PowerShell. Una vez
que haya encontrado el error, siga este documento para solucionar los errores.
No se puede crear una galería de imágenes compartidas

Causas posibles:
El nombre de la galería no es válido.
Los caracteres permitidos para el nombre de la Galería son letras mayúsculas o minúsculas, números y puntos. El
nombre de la galería no puede contener guiones. Cambie el nombre de la galería y vuelva a intentarlo.
El nombre de la galería no es único dentro de la suscripción.
Elija otro nombre de la galería y vuelva a intentarlo.
No es posible crear la definición de una imagen

Causas posibles:
El nombre de la definición de la imagen no es válido.
Los caracteres permitidos para la definición de una imagen son letras mayúsculas o minúsculas, números, guiones
y puntos. Cambie el nombre de la definición de la imagen y vuelva a intentarlo.
No se rellenan las propiedades obligatorias para crear la definición de una imagen.
Las propiedades como el nombre, publicador, oferta, SKU y tipo de sistema operativo son obligatorias.
Compruebe si se pasan todas las propiedades.
Asegúrese de que el valor de OSType, Linux o Windows, de la definición de la imagen sea el mismo que el de la
imagen administrada de origen que usa para crear la versión de la imagen.
No es posible crear la versión de una imagen

Causas posibles:
El nombre de la versión de la imagen no es válido.
del rango de un entero de 32 bits. Formato: VersiónPrincipal.VersiónSecundaria.Revisión. Cambie el nombre de la
versión de la imagen y vuelva a intentarlo.
No se encuentra la imagen administrada de origen a partir la que se crea la versión de la imagen.
Compruebe si la imagen de origen existe y está en la misma región que la versión de la imagen.
No se ha terminado de aprovisionar la imagen administrada.
Asegúrese de que el estado de aprovisionamiento de la imagen administrada de origen sea Correcto.
La lista de regiones de destino no incluye la región de origen.
La lista de regiones de destino debe incluir la región de origen de la versión de la imagen. Asegúrese de haber
incluido la región de origen en la lista de regiones de destino donde quiere que Azure replique la versión de la
imagen.
No se ha completado la replicación en todas las regiones de destino.
Use la marca --expand ReplicationStatus para comprobar si se ha completado la replicación en todas las
regiones de destino especificadas. Si no es así, espere hasta 6 horas para que se complete el trabajo. Si se produce
un error, ejecute el comando de nuevo para crear y replicar la versión de la imagen. Si va a replicar la versión de la
imagen en una gran cantidad de regiones de destino, tenga en cuenta la posibilidad de realizar la replicación en
fases.
No se puede crear una VM o un conjunto de escalado

Causas posibles:
El usuario que intenta crear una VM o un conjunto de escalado de máquinas virtuales no tiene acceso de lectura
a la versión de la imagen.
Póngase en contacto con el propietario de la suscripción y pídale que le conceda acceso de lectura a la versión de
imagen o a los recursos principales (por ejemplo, la galería de imágenes compartidas o la definición de la imagen)
a través de Control de acceso basado en roles (RBAC ).
No se encuentra la versión de la imagen.
Compruebe que la región en la que intenta crear una VM o un conjunto de escalado de máquinas virtuales esté
incluida en la lista de regiones de destino de la versión de la imagen. Si la región ya está en la lista de regiones de
destino, compruebe si se ha completado el trabajo de replicación. Puede usar la marca -ReplicationStatus para
comprobar si se ha completado la replicación en todas las regiones de destino especificadas.
La creación de la VM o el conjunto de escalado de máquinas virtuales tarda mucho tiempo.
Compruebe que el valor de OSType de la versión de la imagen a partir de la cual intenta crear la VM o el
conjunto de escalado de máquinas virtuales tiene el mismo valor de OSType que la imagen administrada de
origen que usó para crear la versión de la imagen.
No se pueden compartir los recursos

El uso compartido de los recursos de la galería de imágenes compartidas, versiones de imágenes y definiciones
de imágenes entre suscripciones se habilita mediante el Control de acceso basado en roles (RBAC ).
La replicación es lenta
Use la marca --expand ReplicationStatus para comprobar si se ha completado la replicación en todas las
regiones de destino especificadas. Si no es así, espere hasta 6 horas para que se complete el trabajo. Si se produce
un error, desencadene el comando de nuevo para crear y replicar la versión de la imagen. Si va a replicar la
versión de la imagen en una gran cantidad de regiones de destino, tenga en cuenta la posibilidad de realizar la
replicación en fases.
Límites y cuotas de Azure

Loslímites y cuotas de Azure se aplican a todos los recursos de galería de imágenes compartidas, las versiones de
imágenes, definiciones de imágenes. Asegúrese de encontrarse dentro de los límites para las suscripciones.
Pasos siguientes
Obtenga más información sobre Shared Image Galleries.
Vista previa: Introducción a Azure Image Builder
Las imágenes estandarizadas de máquinas virtuales permiten a las organizaciones migrar a la nube y garantizar la
coherencia de las implementaciones. Normalmente, las imágenes incluyen opciones de seguridad y de
configuración predefinidas y el software necesario. La configuración de su propia canalización de creación de
imágenes requiere tiempo, una infraestructura y el programa de instalación, pero con Image Builder de máquina
virtual de Azure, basta con que proporcione una configuración sencilla que describa la imagen y la envíe al
servicio para que se cree y se distribuya.
Image Builder de máquina virtual de Azure (Azure Image Builder) le permite empezar con una imagen de Azure
Marketplace basada en Windows o Linux, imágenes personalizadas existentes o ISO de Red Hat Enterprise Linux
(RHEL ) y empezar a agregar sus propias personalizaciones. Image Builder se compila en HashiCorp Packer, por lo
que puede importar incluso los scripts del aprovisionador de shell de Packer existentes. También puede especificar
dónde quiere que se hospeden sus imágenes, en la Azure Shared Image Gallery, como una imagen administrada o
un VHD.
IMPORTANT
Actualmente, el generador de imágenes de Azure se encuentra en versión preliminar pública. Esta versión preliminar se
ofrece sin Acuerdo de Nivel de Servicio y no se recomienda para cargas de trabajo de producción. Es posible que algunas
características no sean compatibles o que tengan sus funcionalidades limitadas. Para más información, consulte Términos de
uso complementarios de las Versiones Preliminares de Microsoft Azure.
Características en vista previa

En la versión preliminar se admiten estas características:
Creación de imágenes de línea de base para comercializar, que incluyen las configuraciones corporativas y de
seguridad mínimas y permiten que los departamentos puedan personalizarlas aún más para sus necesidades.
Aplicación de revisiones de imágenes existentes. Image Builder permitirá revisar continuamente las imágenes
personalizadas existentes.
Integración con Azure Shared Image Gallery, que permite distribuir, crear versiones y escalar imágenes
globalmente y ofrece un sistema de administración de imágenes.
Integración con las canalizaciones de compilación de imágenes existentes. Simplemente llame a Image Builder
desde la canalización o use la tarea sencilla de Azure DevOps de versión preliminar de Image Builder.
Migración de una canalización de personalización de imagen existente a Azure. Use los scripts, comandos y
procesos existentes para personalizar las imágenes.
Use una asistencia de tipo traiga su propia suscripción de Red Hat. Cree imágenes de Red Hat Enterprise para
su uso con las suscripciones aptas y sin usar de Red Hat.
Creación de imágenes en formato VHD.
Regions
El servicio Azure Image Builder estará disponible en versión preliminar en estas regiones. Las imágenes se pueden
distribuir fuera de estas regiones.
East US
Este de EE. UU. 2
Centro occidental de EE.UU.
Oeste de EE. UU.
Oeste de EE. UU. 2
SO compatible
AIB será compatible con imágenes del sistema operativo base de Azure Marketplace:
Ubuntu 18.04
Ubuntu 16.04
RHEL 7.6
CentOS 7.6
Windows 10 RS5 Enterprise/Professional/Enterprise para escritorio virtual (EVD )
Windows 2016
Windows 2019
AIB será compatible con los ISO de RHEL, como un origen para:
RHEL 7.3
RHEL 7.4
RHEL 7.5
ISO de RHEL 7.6 no se admite, pero está en proceso de prueba.
Cómo funciona
Azure Image Builder es un servicio de Azure totalmente administrado al que se accede a través de un proveedor
de recursos de Azure. El proceso Azure Image Builder tiene tres partes principales: origen, personalización y
distribución, representadas en una plantilla. El diagrama siguiente muestra los componentes, con algunas de sus
propiedades.
Proceso de Image Builder
1. Cree la plantilla de imagen como un archivo .json. Este archivo .json contiene información sobre el origen, las
personalizaciones y la distribución de la imagen. Hay varios ejemplos en el repositorio de GitHub de Azure
Image Builder.
2. Al enviarla al servicio, se creará un artefacto de plantilla de imagen en el grupo de recursos que especifique. En
segundo plano, Image Builder descargará la imagen de origen o ISO y los scripts, según sea necesario. Estos se
almacenan en un grupo de recursos independiente que se crea automáticamente en la suscripción, en el
formato siguiente: IT_<DestinationResourceGroup><TemplateName>.
3. Una vez creada la plantilla de imagen, podrá compilar la imagen. En segundo plano, Image Builder utiliza los
archivos de origen y la plantilla para crear una máquina virtual (D1v2), una red, una dirección IP pública y un
almacenamiento en el grupo de recursos IT_<GrupoDeRecursosDeDestino><NombreDePlantilla>.
4. Como parte de la creación de la imagen, Image Builder distribuye la imagen según la plantilla y luego elimina
los recursos adicionales en el grupo de recursos IT_<DestinationResourceGroup > <TemplateName > que se
ha creado para el proceso.
Permisos
Para permitir que Azure VM Image Builder distribuya las imágenes a las imágenes administradas o a Shared
Image Gallery, deberá proporcionar permisos de "colaborador" para el servicio "Azure Virtual Machine Image
Builder" (Id. de aplicación: cf32a0cc-373c-47c9-9156-0db11f6a6dfc ) en los grupos de recursos.
Si usa una imagen administrada personalizada existente o una versión de la imagen, Azure Image Builder
necesitará como mínimo un acceso de "lector" a esos grupos de recursos.
Puede asignar accesos con la CLI de Azure:
az role assignment create \

--assignee cf32a0cc-373c-47c9-9156-0db11f6a6dfc \
--role Contributor \
--scope /subscriptions/$subscriptionID/resourceGroups/<distributeResoureGroupName>
Si no se encuentra la cuenta de servicio, puede que la suscripción en la que va a agregar la asignación de roles aún
no se haya registrado para el proveedor de recursos.
Costos
Se incurrirá en algunos costos de procesos, redes y almacenamiento al crear, compilar y almacenar las imágenes
con Azure Image Builder. Estos costos son similares a los que conlleva la creación manual de imágenes
personalizadas. En el caso de los recursos, se le cargarán las tarifas que tenga en Azure.
Durante el proceso de creación de imagen, los archivos se descargan y se almacenan en el grupo de recursos de
IT_<DestinationResourceGroup>_<TemplateName> , que incurrirá en costos menores de almacenamiento. Si no quiere
conservarlos, elimine la plantilla de imagen después de la compilación de la imagen.
Image Builder crea una máquina virtual con un tamaño D1v2 y el almacenamiento y redes que necesita. Estos
recursos estarán en vigor durante el proceso de compilación y se eliminarán una vez que Image Builder haya
terminado de crear la imagen.
Azure Image Builder distribuirá la imagen a las regiones elegidas, lo que podría suponer cargos de salida de red.
Pasos siguientes
Para probar Azure Image Builder, consulte los artículos para la compilación de imágenes de Linux o Windows.
Vista previa: Creación de una máquina virtual
Windows con Azure Image Builder
En este artículo se muestra cómo puede crear una imagen personalizada de Windows mediante el generador de
imágenes de máquina virtual de Azure. En el ejemplo de este artículo se usan personalizadores para personalizar
la imagen:
PowerShell (ScriptUri): para descargar y ejecutar un script de PowerShell.
Reinicio de Windows: reinicia la máquina virtual.
PowerShell (insertado) ejecuta un comando específico. En este ejemplo, se crea un directorio en la máquina
virtual mediante mkdir c:\\buildActions .
Archivo: para copiar un archivo de GitHub en la máquina virtual. En este ejemplo se copia index.md en
c:\buildArtifacts\index.html en la máquina virtual.
También puede especificar un valor de buildTimeoutInMinutes . El valor predeterminado es de 240 minutos, y

puede aumentar el tiempo de compilación para permitir compilaciones de larga duración.
Se usará una plantilla .json de ejemplo para configurar la imagen. El archivo .json que se usa aquí es:
helloImageTemplateWin.json.
IMPORTANT
Azure Image Builder se encuentra actualmente en versión preliminar pública. Esta versión preliminar se ofrece sin Acuerdo
de Nivel de Servicio y no se recomienda para cargas de trabajo de producción. Es posible que algunas características no sean
Registro de las características

Para usar el generador de imágenes de Azure durante la versión preliminar, tendrá que registrar la nueva
característica.
az feature register --namespace Microsoft.VirtualMachineImages --name VirtualMachineTemplatePreview
Compruebe el estado del registro de la característica.
az feature show --namespace Microsoft.VirtualMachineImages --name VirtualMachineTemplatePreview | grep state
Compruebe el registro.
az provider show -n Microsoft.VirtualMachineImages | grep registrationState
az provider show -n Microsoft.Storage | grep registrationState
Si no se muestran como registradas, ejecute lo siguiente:

az provider register -n Microsoft.VirtualMachineImages
az provider register -n Microsoft.Storage
Configuración de variables
Usaremos algunos datos de forma repetida, por lo que crearemos diversas variables para almacenar esa
información.
# Resource group name - we are using myImageBuilderRG in this example

imageResourceGroup=myWinImgBuilderRG
# Region location
location=WestUS2
# Name for the image
imageName=myWinBuilderImage
# Run output name
runOutputName=aibWindows
# name of the image to be created
imageName=aibWinImage
Cree una variable para el id. de suscripción. Puede obtenerlo mediante az account show | grep id .
subscriptionID=<Your subscription ID>

Este grupo de recursos se usa para almacenar el artefacto de la plantilla de configuración de la imagen y la
imagen misma.
az group create -n $imageResourceGroup -l $location
Establecer permisos en el grupo de recursos

Otorgue el permiso de "colaborador" de Image Builder para crear la imagen en el grupo de recursos. Sin esto, no
se compilará la imagen.
El valor --assignee es el identificador de registro de aplicación para el servicio del generador de imágenes.

--scope /subscriptions/$subscriptionID/resourceGroups/$imageResourceGroup
Descargar el ejemplo de plantilla de configuración de imagen

Se ha creado una plantilla de configuración de imagen con parámetros para que pueda probarla. Descargue el
archivo .json de ejemplo y configúrelo con las variables que estableció anteriormente.
curl
https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/quickquickstarts/0_Creating_a_Custom
_Windows_Managed_Image/helloImageTemplateWin.json -o helloImageTemplateWin.json
sed -i -e "s/<subscriptionID>/$subscriptionID/g" helloImageTemplateWin.json

sed -i -e "s/<rgName>/$imageResourceGroup/g" helloImageTemplateWin.json
sed -i -e "s/<region>/$location/g" helloImageTemplateWin.json
sed -i -e "s/<imageName>/$imageName/g" helloImageTemplateWin.json
sed -i -e "s/<runOutputName>/$runOutputName/g" helloImageTemplateWin.json
Puede modificar este ejemplo en el terminal con un editor de texto, como vi .
vi helloImageTemplateLinux.json
NOTE
Para la imagen de origen, siempre debe especificar una versión; no puede usar latest . Si agrega o cambia el grupo de
recursos adonde se distribuye la imagen, tiene que asegurarse de que los permisos estén establecidos en el grupo de
recursos.
Crear la imagen
Envío de la configuración de la imagen al servicio de generador de imágenes de máquina virtual
az resource create \
--resource-group $imageResourceGroup \
--properties @helloImageTemplateWin.json \
--is-full-object \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-n helloImageTemplateWin01
Cuando haya finalizado, devolverá un mensaje de confirmación a la consola y creará

Image Builder Configuration Template en $imageResourceGroup . Puede ver este recurso en el grupo de recursos en
Azure Portal si habilita "Mostrar tipos ocultos".
Asimismo, Image Builder creará en segundo plano un grupo de recursos de almacenamiento provisional en la
suscripción. Este grupo de recursos se usa para la compilación de la imagen. Tendrá este formato:
IT_<DestinationResourceGroup>_<TemplateName>
NOTE
No debe eliminar el grupo de recursos de almacenamiento provisional directamente. Primero elimine el artefacto de la
plantilla de imagen, esto hará que se elimine el grupo de recursos de almacenamiento provisional.
Si el servicio informa de un error durante el envío de la plantilla de configuración de la imagen:

Revise los pasos para solucionar problemas.
Tendrá que eliminar la plantilla con el siguiente fragmento de código antes de reintentar el envío.
az resource delete \
-n helloImageTemplateLinux01
Iniciar la generación de imágenes

Inicie el proceso de compilación de la imagen con az resource invoke-action.
az resource invoke-action \
-n helloImageTemplateWin01 \
--action Run
Espere hasta que se complete la compilación. Puede tardar unos 15 minutos.

Si encuentra algún error, revise estos pasos para la solución de problemas.

Cree la máquina virtual con la imagen que ha compilado. Reemplace <password> por su propia contraseña para
aibuser en la máquina virtual.
az vm create \
--name aibImgWinVm00 \
--admin-username aibuser \
--admin-password <password> \
--image $imageName \
--location $location
Comprobación de la personalización
Cree una conexión de Escritorio remoto a la máquina virtual con el nombre de usuario y la contraseña que ha
establecido al crear la máquina virtual. Dentro de la máquina virtual, abra un símbolo del sistema y escriba lo
siguiente:
dir c:\
Debería ver estos dos directorios creados durante la personalización de la imagen:

buildActions
buildArtifacts
Limpieza
Cuando haya terminado, elimine los recursos.
Eliminar la plantilla de Image Builder
-n helloImageTemplateWin01
Eliminar el grupo de recursos de imagen
az group delete -n $imageResourceGroup
Pasos siguientes
Para obtener más información sobre los componentes del archivo .json que se usan en este artículo, vea
Referencia de la plantilla de generador de imágenes.
Vista previa: Creación de una imagen de Windows y
distribución en una galería de imágenes compartidas
En este artículo se muestra cómo puede usar Azure Image Builder para crear una versión de imagen en una
galería de imágenes compartidas y después distribuirla globalmente.
Se usará una plantilla .json para configurar la imagen. El archivo .json que se usa aquí es:
helloImageTemplateforWinSIG.json.
Para distribuir la imagen en una galería de imágenes compartidas, en la plantilla se usa sharedImage como valor
de la sección distribute de la plantilla.
IMPORTANT
Azure Image Builder se encuentra actualmente en versión preliminar pública. Esta versión preliminar se ofrece sin Acuerdo de
Nivel de Servicio y no se recomienda para cargas de trabajo de producción. Es posible que algunas características no sean

característica.

az provider show -n Microsoft.Compute | grep registrationState

az provider register -n Microsoft.Compute
Establecimiento de variables y permisos

Se usarán algunos fragmentos de información de forma repetida, por lo que se crearán diversas variables para
almacenar esa información. Reemplace los valores de las variables, como username y vmpassword , por información
propia.
# Resource group name - we are using ibsigRG in this example

sigResourceGroup=myIBWinRG
# Datacenter location - we are using West US 2 in this example
location=westus
# Additional region to replicate the image to - we are using East US in this example
additionalregion=eastus
# name of the shared image gallery - in this example we are using myGallery
sigName=my22stSIG
# name of the image definition to be created - in this example we are using myImageDef
imageDefName=winSvrimages
# image distribution metadata reference name
runOutputName=w2019SigRo
# User name and password for the VM
username="azureuser"
vmpassword="passwordfortheVM"
Cree una variable para el identificador de la suscripción. Puede obtenerlo mediante az account show | grep id .
subscriptionID="Subscription ID"
Cree el grupo de recursos.
az group create -n $sigResourceGroup -l $location
Conceda a Azure Image Builder permiso para crear recursos en ese grupo de recursos. El valor --assignee es el
identificador de registro de aplicación para el servicio Image Builder.

--scope /subscriptions/$subscriptionID/resourceGroups/$sigResourceGroup
Creación de una definición de imagen y una galería

Para usar Image Builder con una galería de imágenes compartidas, debe tener ya una galería de imágenes y una
definición de imagen. Image Builder no creará la galería de imágenes ni la definición de imagen automáticamente.
Si aún no tiene una galería y una definición de imagen para usar, empiece por crearlas. En primer lugar, cree una
galería de imágenes.
az sig create \
-g $sigResourceGroup \
--gallery-name $sigName
Luego, cree una definición de imagen.

az sig image-definition create \
--gallery-name $sigName \
--gallery-image-definition $imageDefName \
--publisher corpIT \
--offer myOffer \
--sku 2019 \
--os-type Windows
Descarga y configuración del archivo .json

Descargue la plantilla .json y configúrela con las variables.
curl
https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/quickquickstarts/1_Creating_a_Custom
_Win_Shared_Image_Gallery_Image/helloImageTemplateforWinSIG.json -o helloImageTemplateforWinSIG.json
sed -i -e "s/<subscriptionID>/$subscriptionID/g" helloImageTemplateforWinSIG.json
sed -i -e "s/<rgName>/$sigResourceGroup/g" helloImageTemplateforWinSIG.json
sed -i -e "s/<imageDefName>/$imageDefName/g" helloImageTemplateforWinSIG.json
sed -i -e "s/<sharedImageGalName>/$sigName/g" helloImageTemplateforWinSIG.json
sed -i -e "s/<region1>/$location/g" helloImageTemplateforWinSIG.json
sed -i -e "s/<region2>/$additionalregion/g" helloImageTemplateforWinSIG.json
sed -i -e "s/<runOutputName>/$runOutputName/g" helloImageTemplateforWinSIG.json
Creación de la versión de la imagen

En la sección siguiente se creará la versión de la imagen en la galería.
Envíe la configuración de la imagen al servicio Azure Image Builder.
--resource-group $sigResourceGroup \
--properties @helloImageTemplateforWinSIG.json \
--is-full-object \
-n helloImageTemplateforWinSIG01
Inicie la generación de imágenes.
-n helloImageTemplateforWinSIG01 \
--action Run
La creación de la imagen y su replicación en las dos regiones puede llevar un tiempo. Espere a que termine esta
parte antes de pasar a la creación de una máquina virtual.

Cree una máquina virtual a partir la versión de la imagen creada por Azure Image Builder.
az vm create \
--admin-username $username \
--admin-password $vmpassword \
--image
"/subscriptions/$subscriptionID/resourceGroups/$sigResourceGroup/providers/Microsoft.Compute/galleries/$sigNam
e/images/$imageDefName/versions/latest" \
siguiente:
dir c:\
Debería ver un directorio con el nombre buildActions , que se ha creado durante la personalización de la imagen.
Si ahora quiere volver a personalizar la versión de la imagen para crear una nueva de la misma imagen, omita
este paso y vaya a Uso de Azure Image Builder para crear otra versión de la imagen.
Esta acción eliminará la imagen que se ha creado, junto con todos los demás archivos de recursos. Asegúrese de
que haya terminado con esta implementación antes de eliminar los recursos.
Al eliminar los recursos de la galería de imágenes, tendrá que eliminar todas las versiones de la imagen antes de
poder eliminar la definición de la imagen que se ha usado para crearlas. Para eliminar una galería, primero tiene
que haber eliminado todas las definiciones de imagen de la galería.
Elimine la plantilla de Azure Image Builder.
-n helloImageTemplateforWinSIG01
Obtenga la versión de la imagen creada por el generador de imágenes, que siempre empieza por 0. , y después
elimínela.
sigDefImgVersion=$(az sig image-version list \

--subscription $subscriptionID --query [].'name' -o json | grep 0. | tr -d '"')
az sig image-version delete \
--gallery-image-version $sigDefImgVersion \
--subscription $subscriptionID
Elimine la definición de la imagen.

az sig image-definition delete \
--subscription $subscriptionID
Elimine la galería.
az sig delete -r $sigName -g $sigResourceGroup
Elimine el grupo de recursos.
az group delete -n $sigResourceGroup -y
Pasos siguientes
Para obtener información sobre cómo actualizar la versión de la imagen que ha creado, vea Uso de Azure Image
Builder para crear otra versión de la imagen.
Vista previa: Creación de una versión de imagen a
partir de otra ya existente con Azure Image Builder
En este artículo se muestra cómo tomar una versión de imagen existente en una galería de imágenes
compartidas, actualizarla y publicarla como una nueva versión de imagen en la galería.
Se usará una plantilla .json de ejemplo para configurar la imagen. El archivo .json que se usa aquí es:
helloImageTemplateforSIGfromWinSIG.json.
IMPORTANT
Azure Image Builder se encuentra actualmente en versión preliminar pública. Esta versión preliminar se ofrece sin Acuerdo

característica.

az provider show -n Microsoft.Compute | grep registrationState

az provider register -n Microsoft.Compute
Establecimiento de variables y permisos

Si ha usado Crear una imagen y distribuirla a una galería de imágenes compartidas para crear la galería de
imágenes compartidas, ya se han creado las variables necesarias. Si no es así, configure algunas variables para
usarlas en este ejemplo.
Para la versión preliminar, el generador de imágenes solo admitirá la creación de imágenes personalizadas en el
mismo grupo de recursos que la imagen administrada de origen. Actualice el nombre del grupo de recursos de
este ejemplo para que coincida con el de la imagen administrada de origen.
# Resource group name - we are using ibsigRG in this example

sigResourceGroup=myIBWinRG
# Datacenter location - we are using West US 2 in this example
location=westus
# Additional region to replicate the image to - we are using East US in this example
additionalregion=eastus
# name of the shared image gallery - in this example we are using myGallery
sigName=my22stSIG
# name of the image definition to be created - in this example we are using myImageDef
imageDefName=winSvrimages
runOutputName=w2019SigRo
# User name and password for the VM
username="user name for the VM"
vmpassword="password for the VM"
Cree una variable para el identificador de la suscripción. Puede obtenerlo mediante az account show | grep id .
subscriptionID=<Subscription ID>
Obtenga la versión de la imagen que quiera actualizar.
sigDefImgVersionId=$(az sig image-version list \

--subscription $subscriptionID --query [].'id' -o json | grep 0. | tr -d '"' | tr -d '[:space:]')
Si ya tiene una galería de imágenes compartidas propia y no ha seguido el ejemplo anterior, tendrá que asignar
permisos a Image Builder para acceder al grupo de recursos, para que pueda acceder a la galería.

--scope /subscriptions/$subscriptionID/resourceGroups/$sigResourceGroup
Modificación del ejemplo helloImage

Para revisar el ejemplo que se va a usar, abra el archivo .json aquí: helloImageTemplateforSIGfromSIG.json junto
con la referencia de plantillas de Image Builder.
Descargue el ejemplo de .json y configúrelo con las variables.
curl
https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/quickquickstarts/8_Creating_a_Custo
m_Win_Shared_Image_Gallery_Image_from_SIG/helloImageTemplateforSIGfromWinSIG.json -o
helloImageTemplateforSIGfromWinSIG.json
sed -i -e "s/<subscriptionID>/$subscriptionID/g" helloImageTemplateforSIGfromWinSIG.json
sed -i -e "s/<rgName>/$sigResourceGroup/g" helloImageTemplateforSIGfromWinSIG.json
sed -i -e "s/<imageDefName>/$imageDefName/g" helloImageTemplateforSIGfromWinSIG.json
sed -i -e "s/<sharedImageGalName>/$sigName/g" helloImageTemplateforSIGfromWinSIG.json
sed -i -e "s%<sigDefImgVersionId>%$sigDefImgVersionId%g" helloImageTemplateforSIGfromWinSIG.json
sed -i -e "s/<region1>/$location/g" helloImageTemplateforSIGfromWinSIG.json
sed -i -e "s/<region2>/$additionalregion/g" helloImageTemplateforSIGfromWinSIG.json
sed -i -e "s/<runOutputName>/$runOutputName/g" helloImageTemplateforSIGfromWinSIG.json
Crear la imagen
Envíe la configuración de la imagen al servicio de generador de imágenes de máquina virtual.
--properties @helloImageTemplateforSIGfromWinSIG.json \
--is-full-object \
-n imageTemplateforSIGfromWinSIG01
-n imageTemplateforSIGfromWinSIG01 \
--action Run
Espere hasta que se haya creado la imagen y la replicación antes de continuar con el paso siguiente.

az vm create \
--admin-username $username \
--admin-password $vmpassword \
--image
"/subscriptions/$subscriptionID/resourceGroups/$sigResourceGroup/providers/Microsoft.Compute/galleries/$sigNa
me/images/$imageDefName/versions/latest" \
siguiente:
dir c:\
Ahora debería ver dos directorios:

buildActions que se ha creado en la primera versión de imagen.
buildActions2 que se ha creado como parte de la actualización de la primera versión de imagen para crear la
segunda.
Pasos siguientes
Para obtener más información sobre los componentes del archivo .json que se usan en este artículo, vea
Referencia de la plantilla de generador de imágenes.
Creación de una imagen y usar una identidad
administrada asignada por el usuario para acceder a
archivos en Azure Storage
El generador de imágenes de Azure admite el uso de scripts o la copia de archivos desde varias ubicaciones, como
GitHub, Azure Storage, etc. Para utilizarlos, el generador de imágenes de Azure debe haber podido acceder
externamente a ellos, pero puede proteger los blobs de Azure Storage mediante tokens de SAS.
En este artículo se muestra cómo crear una imagen personalizada mediante el generador de imágenes de máquina
virtual de Azure, en que el servicio usará una identidad administrada asignada por el usuario para acceder a los
archivos de Azure Storage para personalizar la imagen, sin tener que dar acceso público a los archivos ni
configurar tokens de SAS.
En el ejemplo siguiente, creará dos grupos de recursos: uno se utilizará para la imagen personalizada y el otro
hospedará una cuenta de Azure Storage, que contiene un archivo de script. Esto simula un escenario real, en que
puede tener los artefactos de compilación o los archivos de imagen en diferentes cuentas de almacenamiento, al
margen del generador de imágenes. Creará una identidad asignada por el usuario y, a continuación, concederá
permisos de lectura en el archivo de script, pero no establecerá ningún acceso público a ese archivo. Después,
usará el personalizador de shell para descargar y ejecutar ese script desde la cuenta de almacenamiento.
IMPORTANT
Actualmente, el generador de imágenes de Azure se encuentra en versión preliminar pública. Esta versión preliminar se ofrece
sin Acuerdo de Nivel de Servicio y no se recomienda para cargas de trabajo de producción. Es posible que algunas
características no sean compatibles o que tengan sus funcionalidades limitadas. Para más información, consulte Términos de
uso complementarios de las Versiones Preliminares de Microsoft Azure.

característica.


Usaremos algunos datos de forma repetida, por lo que crearemos diversas variables para almacenar esa
información.
# Image resource group name

imageResourceGroup=aibmdimsi
# storage resource group
strResourceGroup=aibmdimsistor
# Location
location=WestUS2
# name of the image to be created
imageName=aibCustLinuxImgMsi01
runOutputName=u1804ManImgMsiro
Cree una variable para el id. de suscripción. Puede obtenerlo mediante az account show | grep id .
subscriptionID=<Your subscription ID>
Cree los grupos de recursos para la imagen y el almacenamiento del script.
# create resource group for image template

az group create -n $imageResourceGroup -l $location
# create resource group for the script storage
az group create -n $strResourceGroup -l $location
Cree el almacenamiento y copie ahí el script de ejemplo de GitHub.
# script storage account

scriptStorageAcc=aibstorscript$(date +'%s')
# script container
scriptStorageAccContainer=scriptscont$(date +'%s')
# script url
scriptUrl=https://$scriptStorageAcc.blob.core.windows.net/$scriptStorageAccContainer/customizeScript.sh
# create storage account and blob in resource group

az storage account create -n $scriptStorageAcc -g $strResourceGroup -l $location --sku Standard_LRS
az storage container create -n $scriptStorageAccContainer --fail-on-exist --account-name $scriptStorageAcc
# copy in an example script from the GitHub repo

az storage blob copy start \
--destination-blob customizeScript.sh \
--destination-container $scriptStorageAccContainer \
--account-name $scriptStorageAcc \
--source-uri
https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/quickquickstarts/customizeScript.sh
Conceda al generador de imágenes permiso para crear recursos en el grupo de recursos de imagen. El valor
--assignee es el identificador de registro de aplicación para el servicio del generador de imágenes.
--scope /subscriptions/$subscriptionID/resourceGroups/$imageResourceGroup
Creación de una identidad administrada asignada por el usuario

Cree la identidad y asigne permisos para la cuenta de almacenamiento del script. Para obtener más información,
consulte Identidad administrada asignada por el usuario.
# Create the user assigned identity

identityName=aibBuiUserId$(date +'%s')
az identity create -g $imageResourceGroup -n $identityName
# assign the identity permissions to the storage account, so it can read the script blob
imgBuilderCliId=$(az identity show -g $imageResourceGroup -n $identityName | grep "clientId" | cut -c16- | tr -
d '",')
--assignee $imgBuilderCliId \
--role "Storage Blob Data Reader" \
--scope
/subscriptions/$subscriptionID/resourceGroups/$strResourceGroup/providers/Microsoft.Storage/storageAccounts/$sc
riptStorageAcc/blobServices/default/containers/$scriptStorageAccContainer
# create the user identity URI
imgBuilderId=/subscriptions/$subscriptionID/resourcegroups/$imageResourceGroup/providers/Microsoft.ManagedIdent
ity/userAssignedIdentities/$identityName
Modificación del ejemplo

Descargue el archivo .json de ejemplo y configúrelo con las variables que ha creado.
curl
https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/quickquickstarts/7_Creating_Custom_Im
age_using_MSI_to_Access_Storage/helloImageTemplateMsi.json -o helloImageTemplateMsi.json
sed -i -e "s/<subscriptionID>/$subscriptionID/g" helloImageTemplateMsi.json
sed -i -e "s/<rgName>/$imageResourceGroup/g" helloImageTemplateMsi.json
sed -i -e "s/<region>/$location/g" helloImageTemplateMsi.json
sed -i -e "s/<imageName>/$imageName/g" helloImageTemplateMsi.json
sed -i -e "s%<scriptUrl>%$scriptUrl%g" helloImageTemplateMsi.json
sed -i -e "s%<imgBuilderId>%$imgBuilderId%g" helloImageTemplateMsi.json
sed -i -e "s%<runOutputName>%$runOutputName%g" helloImageTemplateMsi.json
Crear la imagen
Envíe la configuración de la imagen al servicio del generador de imágenes de Azure.
--properties @helloImageTemplateMsi.json \
--is-full-object \
-n helloImageTemplateMsi01

-n helloImageTemplateMsi01 \
--action Run
Espere a que la compilación finalice. Puede tardar unos 15 minutos.
Crear una VM
Cree una máquina virtual a partir de la imagen.
az vm create \
--name aibImgVm00 \
--admin-username aibuser \
--image $imageName \
--location $location \
--generate-ssh-keys
Una vez creada la máquina virtual, inicie una sesión de SSH con la máquina virtual.
ssh aibuser@<publicIp>
Verá que la imagen se ha personalizado con un mensaje del día en cuanto se ha establecido la conexión SSH.
*******************************************************
** This VM was built from the: **
** !! AZURE VM IMAGE BUILDER Custom Image !! **
** You have just been Customized :-) **
*******************************************************
Limpieza
Cuando haya terminado, puede eliminar los recursos si ya no son necesarios.
az identity delete --ids $imgBuilderId

-n helloImageTemplateMsi01
az group delete -n $imageResourceGroup
az group delete -n $strResourceGroup
Pasos siguientes
Si tiene algún problema para trabajar con el generador de imágenes de Azure, consulte Solucionar problemas.
Vista previa: Creación de una plantilla de Azure Image Builder
Azure Image Builder utiliza un archivo .json para trasladar la información al servicio Image Builder. En este artículo analizaremos las secciones del archivo json, para
que pueda compilar su propio archivo. Para ver ejemplos de archivos .json completos, consulte el GitHub de Azure Image Builder.
Este es el formato de plantilla básico:
{
"type": "Microsoft.VirtualMachineImages/imageTemplates",
"location": "<region>",
"tags": {
"<name": "<value>",
"<name>": "<value>"
}
"identity":{},
"dependsOn": [],
"properties": {
"buildTimeoutInMinutes": <minutes>,
"build": {},
"customize": {},
"distribute": {}
}
}
Tipo y versión de API

type es el tipo de recurso, que debe ser "Microsoft.VirtualMachineImages/imageTemplates" . apiVersion cambiará con el tiempo a medida que cambie la API, pero
debería ser "2019-05-01-preview" para la versión preliminar.
"type": "Microsoft.VirtualMachineImages/imageTemplates",
Location
La ubicación es la región donde se creará la imagen personalizada. Para la versión preliminar de Image Builder, se admiten las siguientes regiones:
East US
Este de EE. UU. 2
Centro occidental de EE.UU.
Oeste de EE. UU.
Oeste de EE. UU. 2
Etiquetas
Estos son los pares clave-valor que puede especificar para la imagen que se genera.
Dependencia (opcional)
Esta sección opcional se puede usar para asegurarse de que las dependencias se completan antes de continuar.
"dependsOn": [],
Para obtener más información, consulte Definir dependencias de recursos.
Identidad
De forma predeterminada, Image Builder admite el uso de scripts o la copia de archivos desde varias ubicaciones, como, por ejemplo, GitHub y Azure Storage. Para
utilizar estos servicios, deben estar accesibles públicamente.
También puede usar una identidad administrada de Azure asignada por el usuario, que usted habrá definido, para permitir que Image Builder acceda a Azure Storage,
siempre que la identidad tenga como mínimo el permiso de "Lector de datos de Storage Blob" en la cuenta de Azure Storage. Esto significa que no es necesario que los
blobs de almacenamiento sean accesibles externamente ni configurar tokens SAS de instalación.
"identity": {
"type": "UserAssigned",
"userAssignedIdentities": {
"<imgBuilderId>": {}
}
},
Para ver un ejemplo completo, consulte Usar una identidad administrada de Azure asignada por el usuario para acceder a los archivos de Azure Storage.
Compatibilidad de Image Builder para una identidad asignada por el usuario: • Solo admite una identidad • No admite nombres de dominio personalizados
Para obtener más información, consulte ¿Qué son las identidades administradas para los recursos de Azure? Para obtener más información sobre la implementación de
esta característica, consulte Configurar identidades administradas para los recursos de Azure en una máquina virtual de Azure mediante la CLI de Azure.
Propiedades: origen
La sección source contiene información acerca de la imagen de origen que usará Image Builder.
La API requiere un "SourceType" que define el origen de la compilación de imagen. Actualmente hay tres tipos:
ISO: utilice esta opción cuando el origen sea un ISO de RHEL.
PlatformImage: indicado para los casos en que la imagen de origen es una imagen de Marketplace.
ManagedImage: use esta opción cuando empiece desde una imagen administrada normal.
SharedImageVersion: se utiliza cuando se usa como origen una versión de la imagen de una galería de imágenes compartidas.
Origen de ISO
Para la versión preliminar, Azure Image Builder solo admite el uso de ISO de DVD binarios de Red Hat Enterprise Linux 7.x publicados. Image Builder admite:
RHEL 7.3
RHEL 7.4
RHEL 7.5
"source": {
"type": "ISO",
"sourceURI": "<sourceURI from the download center>",
"sha256Checksum": "<checksum associated with ISO>"
}
Para obtener los valores sourceURI y sha256Checksum , vaya a https://access.redhat.com/downloads y, a continuación, seleccione el producto Red Hat Enterprise Linux
y una versión compatible.
En la lista de Instaladores e imágenes para Red Hat Enterprise Linux Server, deberá copiar el vínculo de DVD binario de Red Hat Enterprise Linux 7.x y la suma de
comprobación.
NOTE
Los tokens de acceso de los vínculos se actualizan a intervalos frecuentes, por lo que, cada vez que desee enviar una plantilla, deberá comprobar si la dirección del vínculo de RH ha
cambiado.
Origen de PlatformImage
Azure Image Builder admite las siguientes imágenes de Azure Marketplace:
Ubuntu 18.04
Ubuntu 16.04
RHEL 7.6
CentOS 7.6
Windows 2016
Windows 2019
"source": {
"type": "PlatformImage",
"publisher": "Canonical",
"offer": "UbuntuServer",
"sku": "18.04-LTS",
"version": "18.04.201903060"
},
Aquí, las propiedades son las mismas que se utilizan para crear máquinas virtuales. Mediante la CLI de Azure, ejecute lo siguiente para obtener las propiedades:
az vm image list -l westus -f UbuntuServer -p Canonical --output table –-all
NOTE
La versión no puede ser la "más reciente", deberá usar el comando anterior para obtener un número de versión.
Origen de ManagedImage
Establece la imagen de origen como una imagen administrada existente de una máquina virtual o un disco duro virtual generalizados. La imagen administrada de
origen debe ser de un sistema operativo compatible y encontrarse en la misma región que la plantilla de Azure Image Builder.
"source": {
"type": "ManagedImage",
"imageId": "/subscriptions/<subscriptionId>/resourceGroups/{destinationResourceGroupName}/providers/Microsoft.Compute/images/<imageName>"
}
imageId debe ser el valor de ResourceId de la imagen administrada. Use az image list para enumerar las imágenes disponibles.
Origen de SharedImageVersion
Establece la imagen de origen en una versión de la imagen existente de una galería de imágenes compartidas. La versión de la imagen debe ser de un sistema
operativo compatible y la imagen debe replicarse a la misma región que la plantilla de Azure Image Builder.
"source": {
"type": "SharedImageVersion",
"imageVersionID": "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/p
roviders/Microsoft.Compute/galleries/<sharedImageGalleryName>/images/<imageDefinitionName/versions/<imageVersion>"
}
El imageVersionId debe ser el valor de ResourceId de la versión de la imagen. Use lista de versiones de imagen con firma de Azure para obtener una lista de las
versiones de imagen.
Propiedades: buildTimeoutInMinutes
De manera predeterminada, Image Builder se ejecutará durante 240 minutos. Después de esto, se agotará el tiempo de espera y se detendrá, así se haya completado la
compilación de la imagen como si no. Si se alcanza el tiempo de espera, verá un error similar al siguiente:
[ERROR] Failed while waiting for packerizer: Timeout waiting for microservice to
[ERROR] complete: 'context deadline exceeded'
Si no se especifica un valor de buildTimeoutInMinutes o se establece en 0, se usará el valor predeterminado. Puede aumentar o disminuir el valor, hasta el máximo de
960 min (16 horas). En Windows, no se recomienda establecer este valor por debajo de 60 minutos. Si alcanza el tiempo de espera, revise los registros para ver si el
paso de personalización está esperando algo, como la entrada del usuario.
Si necesita más tiempo para que se completen las personalizaciones, establezca el valor en lo que crea que necesita, con una pequeña sobrecarga. Pero no lo establezca
demasiado alto, ya que es posible que tenga que esperar a que se agote el tiempo de espera antes de ver un error.
Propiedades: personalización
Image Builder admite varios "personalizadores". Los personalizadores son funciones que se utilizan para personalizar la imagen, como, por ejemplo, ejecutar scripts o
reiniciar los servidores.
Al usar customize :
Puede usar varios personalizadores, pero deben tener un único name .
Los personalizadores se ejecutan en el orden especificado en la plantilla.
Si se produce un error en un personalizador, todo el componente de personalización producirá un error e informará de un error.
Es muy recomendable que pruebe exhaustivamente el script antes de usarlo en una plantilla. Será más fácil depurar el script en su propia máquina virtual.
No incluya información confidencial en los scripts.
Las ubicaciones de los scripts deben estar accesibles públicamente, a menos que esté usando MSI.
"customize": [
{
"type": "Shell",
"name": "<name>",
"scriptUri": "<path to script>"
},
{
"type": "Shell",
"name": "<name>",
"inline": [
"<command to run inline>",
]
}
],
La sección de personalización es una matriz. Azure Image Builder recorrerá los personalizadores en orden secuencial. Cualquier error en un personalizador producirá
un error en el proceso de compilación.
Personalizador de shell
El personalizador de shell admite la ejecución de scripts de shell, que deben estar accesibles públicamente para que IB pueda acceder a ellos.
"customize": [
{
"type": "Shell",
"name": "<name>",
"scriptUri": "<link to script>"
},
],
"customize": [
{
"type": "Shell",
"name": "<name>",
"inline": "<commands to run>"
},
],
SO compatible: Linux
Propiedades de personalización:
tipo: Shell
nombre: nombre para realizar el seguimiento de la personalización
scriptUri: URI a la ubicación del archivo
inline: matriz de comandos de shell, separados por comas.
NOTE
Al ejecutar el personalizador de shell con el origen ISO de RHEL, deberá asegurarse de que el primer shell de personalización admite el registro con un servidor de derechos de Red Hat
antes de que se produzca cualquier personalización. Una vez completada la personalización, deberá anular el registro del script con el servidor de derechos.
Personalizador de reinicio de Windows

El personalizador de reinicio le permite reiniciar una máquina virtual de Windows y esperar a que vuelva a conectarse, lo que le permite instalar software que requiere
un reinicio.
"customize": [
"type{ ": "WindowsRestart",
"restartCommand": "shutdown /r /f /t 0 /c",
"restartCheckCommand": "echo Azure-Image-Builder-Restarted-the-VM > buildArtifacts/azureImageBuilderRestart.txt",
"restartTimeout": "5m"
}],
SO compatible: Windows
Tipo: WindowsRestart
restartCommand: comando para ejecutar el reinicio (opcional). El valor predeterminado es 'shutdown /r /f /t 0 /c \"packer restart\"' .
restartCheckCommand: comando para comprobar si el reinicio se realizó correctamente (opcional).
restartTimeout: tiempo de expiración del reinicio especificado como una cadena de magnitud y unidad. Por ejemplo, 5m (5 minutos) o 2h (2 horas). El valor
predeterminado es: "5 m"
Personalizador de PowerShell
El personalizador de shell admite la ejecución de scripts de PowerShell y comandos alineados; los scripts deben estar accesibles públicamente para que IB pueda
acceder a ellos.
"customize": [
{
"type": "PowerShell",
"name": "<name>",
"scriptUri": "<path to script>"
},
{
"type": "PowerShell",
"name": "<name>",
"inline": "<PowerShell syntax to run>",
"valid_exit_codes": "<exit code>"
}
],
SO compatible: Windows y Linux

type: PowerShell.
scriptUri: URI a la ubicación del archivo de script de PowerShell.
inline: comandos alineados que se ejecutarán, separados por comas.
valid_exit_codes: opcional, códigos válidos que pueden devolverse desde el comando de script o alineado; esto evitará que se informe de un error del comando de
script o alineado.
Personalizador de archivos
El personalizador de archivos permite que el generador de imágenes descargue un archivo desde un almacenamiento de GitHub o Azure Storage. Si tiene una
canalización de compilación de imagen basada en artefactos de compilación, puede configurar el personalizador de archivos para que se descargue desde el recurso
compartido de la compilación y mover los artefactos a la imagen.
"customize": [
{
"type": "File",
"name": "<name>",
"sourceUri": "<source location>",
"destination": "<destination>"
}
]
SO compatible: Linux y Windows

Propiedades del personalizador de archivos:
sourceUri: un punto de conexión de almacenamiento accesible, puede tratarse de GitHub o Azure Storage. Solo puede descargar un archivo, no un directorio
completo. Si necesita descargar un directorio, utilice un archivo comprimido y, a continuación, descomprímalo mediante los personalizadores de Shell o PowerShell.
destination: es la ruta de acceso completa y el nombre de archivo de destino. Todas las rutas de acceso y los subdirectorios a los que se hace referencia deben
existir; use los personalizadores de Shell o PowerShell para establecerlos con antelación. Puede usar los personalizadores de script para crear la ruta de acceso.
Los directorios de Windows y las rutas de acceso de Linux lo admiten, aunque hay algunas diferencias:
Sistema operativo Linux: la única ruta de acceso en la que el generador de imágenes puede escribir es /tmp.
Windows: no hay ninguna restricción en la ruta de acceso, pero esta debe existir.
Si se produce un error al intentar descargar el archivo o colocarlo en un directorio concreto, se producirá un error en el paso de personalización, que se registrará en
customization.log.
NOTE
el personalizador de archivos solo es adecuado para descargas de archivos pequeños, inferiores a 20 MB. Para descargas de archivos más grandes, use un script o un comando
insertado, el código de uso para descargar archivos, como wget o curl de Linux, o Invoke-WebRequest de Windows.
Los archivos del personalizador de archivos se pueden descargar desde Azure Storage mediante MSI.
Generalize
De forma predeterminada, Azure Image Builder también ejecutará código de "desaprovisionamiento" al final de cada fase de personalización de la imagen con el fin de
"generalizar" la imagen. La generalización es un proceso en el que la imagen se configura para que pueda volver a usarse para crear varias máquinas virtuales. Para las
máquinas virtuales de Windows, Azure Image Builder utiliza Sysprep. Para Linux, Azure Image Builder ejecuta "waagent-deprovision".
Es posible que los comandos que utiliza Image Builder para la generalización no sean adecuados para todas las situaciones, por lo que Azure Image Builder le permitirá
personalizar este comando si es necesario.
Si está migrando una personalización existente y usa comandos Sysprep/waagent diferentes, puede usar los comandos genéricos de Image Builder y, si la creación de
la máquina virtual produce un error, usar sus propios comandos Sysprep o waagent.
Si Azure Image Builder crea una imagen personalizada de Windows correctamente y usted crea una máquina virtual a partir de ella pero la creación produce un error o
no se realiza correctamente, deberá revisar la documentación de Windows Server Sysprep o presentar una solicitud de soporte técnico al equipo de soporte técnico del
Servicio al cliente de Windows Server Sysprep, quien podrá solucionar problemas y orientarlo en la utilización correcta de Sysprep.
Comando de Sysprep predeterminado
echo '>>> Waiting for GA to start ...'

while ((Get-Service RdAgent).Status -ne 'Running') { Start-Sleep -s 5 }
while ((Get-Service WindowsAzureTelemetryService).Status -ne 'Running') { Start-Sleep -s 5 }
while ((Get-Service WindowsAzureGuestAgent).Status -ne 'Running') { Start-Sleep -s 5 }
echo '>>> Sysprepping VM ...'
if( Test-Path $Env:SystemRoot\\windows\\system32\\Sysprep\\unattend.xml ){ rm $Env:SystemRoot\\windows\\system32\\Sysprep\\unattend.xml -Force} &
$Env:SystemRoot\\System32\\Sysprep\\Sysprep.exe /oobe /generalize /quiet /quit
while($true) { $imageState = Get-ItemProperty HKLM:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Setup\\State | Select ImageState; if($imageState.ImageState -ne
'IMAGE_STATE_GENERALIZE_RESEAL_TO_OOBE') { Write-Output $imageState.ImageState; Start-Sleep -s 5 } else { break } }
Comando de desaprovisionamiento de Linux predeterminado
/usr/sbin/waagent -force -deprovision+user && export HISTSIZE=0 && sync
Reemplazo de los comandos

Para reemplazar los comandos, use los aprovisionadores de scripts de PowerShell o Shell para crear los archivos de comandos con el nombre de archivo exacto y
colóquelos en los directorios correctos:
Windows: c:\DeprovisioningScript.ps1
Linux: /tmp/DeprovisioningScript.sh
Image Builder leerá estos comandos, que se escriben en los registros de AIB, "customization.log". Consulte la solución de problemas sobre cómo recopilar registros.
Propiedades: distribución
Azure Image Builder admite tres destinos de distribución:
managedImage: imagen administrada.
sharedImage: galería de imágenes compartidas.
VHD: disco duro virtual en una cuenta de almacenamiento.
Puede distribuir una imagen a ambos tipos de destino en la misma configuración; para ello, consulte estos ejemplos.
Dado que puede tener más de un destino al que distribuir, Image Builder mantiene un estado para cada destino de distribución al que puede accederse consultando el
runOutputName . El runOutputName es un objeto que puede consultar después de la distribución para obtener información acerca de esa distribución. Por ejemplo, puede
consultar la ubicación del disco duro virtual o las regiones a las que se ha replicado la versión de la imagen. Se trata de una propiedad de cada destino de distribución.
El runOutputName debe ser único para cada destino de distribución.
Distribución: managedImage
El resultado de la imagen será un recurso de imagen administrada.
"distribute": [
{
"type":"managedImage",
"imageId": "<resource ID>",
"runOutputName": "<name>",
"artifactTags": {
"<name": "<value>",
"<name>": "<value>"
}
}]
Propiedades de la distribución:
type: managedImage
imageId: identificador de recurso de la imagen de destino, formato esperado:
/subscriptions/<subscriptionId>/resourceGroups/<destinationResourceGroupName>/providers/Microsoft.Compute/images/<imageName>
location: ubicación de la imagen administrada.
runOutputName: nombre único para identificar la distribución.
artifactTags: etiquetas de par clave-valor opcionales especificadas por el usuario.
NOTE
El grupo de recursos de destino debe existir. Si quiere que la imagen se distribuya a otra región, el tiempo de implementación será mayor.
Distribución: sharedImage
La Galería de imágenes compartidas de Azure es un nuevo servicio de administración de imágenes que permite administrar la replicación de las regiones de la imagen,
el control de versiones y el uso compartido de imágenes personalizadas. Azure Image Builder admite la distribución con este servicio, por lo que puede distribuir
imágenes a las regiones admitidas por las galerías de imágenes compartidas.
Una galería de imágenes compartidas tiene los siguientes componentes:
Galería: contenedor para varias imágenes compartidas. Una galería se implementa en una región.
Definiciones de imagen: una agrupación conceptual para las imágenes.
Versiones de las imágenes: se trata de un tipo de imagen usado para implementar una máquina virtual o un conjunto de escalado. Las versiones de las imágenes se
pueden replicar a otras regiones en las que deban implementarse máquinas virtuales.
Antes de poder distribuir a la Galería de imágenes, debe crear una galería y una definición de imagen; para ello, consulte Imágenes compartidas.
{
"type": "sharedImage",
"galleryImageId": "<resource ID>",
"runOutputName": "<name>",
"artifactTags": {
"<name>": "<value>",
"<name>": "<value>"
},
"replicationRegions": [
"<region where the gallery is deployed>",
"<region>"
]
}
Propiedades de la distribución para las galerías de imágenes compartidas:

tipo: sharedImage
galleryImageId: id. de la galería de imágenes compartidas. El formato es:
/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Compute/galleries/<sharedImageGalleryName>/images/<imageGalleryName>.
artifactTags: etiquetas de par clave-valor opcionales especificadas por el usuario.
replicationRegions: matriz de regiones para la replicación. Una de las regiones debe ser la región en la que está implementada la galería.
NOTE
Puede usar Azure Image Builder en una región distinta a la de la galería, pero el servicio Azure Image Builder tendrá que transferir la imagen entre los centros de datos, lo que requerirá
más tiempo. Image Builder creará automáticamente una versión de la imagen, basándose en un entero monotónico. Actualmente no lo puede especificar.
Distribución: VHD
Puede generar un disco duro virtual. A continuación, puede copiar el disco duro virtual y usarlo para publicar en Azure MarketPlace o usarlo con Azure Stack.
{
"type": "VHD",
"runOutputName": "<VHD name>",
"tags": {
"<name": "<value>",
"<name>": "<value>"
}
}
SO compatible: Windows y Linux

Parámetros de distribución de VHD:
tipo: VHD.
etiquetas: etiquetas de par clave-valor opcionales especificadas por el usuario.
Azure Image Builder no permite al usuario especificar una ubicación de la cuenta de almacenamiento, pero puede consultar el estado de runOutputs para obtener la
ubicación.
az resource show \
--ids
"/subscriptions/$subscriptionId/resourcegroups/<imageResourceGroup>/providers/Microsoft.VirtualMachineImages/imageTemplates/<imageTemplateName>/runOutputs/<runOut
putName>" | grep artifactUri
NOTE
Una vez creado el disco duro virtual, cópielo en una ubicación distinta tan pronto como sea posible. El disco duro virtual se almacena en una cuenta de almacenamiento del grupo de
recursos temporal creado al enviar la plantilla de imagen al servicio Azure Image Builder. Si elimina la plantilla de imagen, perderá el disco duro virtual.
Pasos siguientes
Encontrará archivos .json de ejemplo para diferentes escenarios en el GitHub de Azure Image Builder.
Buscar imágenes de VM de Windows en Azure
Marketplace con Azure PowerShell
En este artículo se describe cómo usar Azure PowerShell para buscar imágenes de VM en Azure Marketplace. A
continuación, puede especificar una imagen de Marketplace cuando se crea una máquina virtual mediante
programación con PowerShell, plantillas de Resource Manager u otras herramientas.
También puede examinar las imágenes y ofertas disponibles mediante el escaparate de Azure Marketplace, Azure
Portal o la CLI de Azure.
Terminología
Una imagen de Marketplace de Azure tiene los atributos siguientes:
Publicador: Organización que ha creado la imagen. Ejemplos: Canonical, MicrosoftWindowsServer
Oferta: nombre de un grupo de imágenes relacionadas creadas por un publicador. Ejemplos: UbuntuServer,
WindowsServer
SKU: Instancia de una oferta, por ejemplo, una versión principal de una distribución. Ejemplos: 18.04-LTS,
2019-Datacenter
Versión: número de versión de una SKU de imagen.
Para identificar una imagen de Marketplace cuando se implementa una máquina virtual mediante programación,
brinde estos valores de manera individual como parámetros. Algunas herramientas aceptan un URN de imagen
que combina estos valores separados por el carácter de dos puntos (:): Publicador:Oferta:SKU:Versión. En un
URN, puede reemplazar el número de versión por "latest", que selecciona la versión más reciente de la imagen.
Si el publicador de la imagen proporciona términos adicionales de licencia y compra, debe aceptar esos términos
y habilitar la implementación mediante programación. También debe suministrar los parámetros de plan de
compra al implementar una máquina virtual mediante programación. Consulte la sección Implementación de una
imagen con términos de Marketplace.
Tabla de imágenes de Windows más usadas

Esta tabla muestra un subconjunto de las SKU disponibles para los publicadores y ofertas indicados.
PUBLICADOR OFERTA SKU
Microsoft Windows Server Windows Server 2019-Datacenter
Microsoft Windows Server Windows Server 2019-Datacenter-Core
Microsoft Windows Server Windows Server 2019-Datacenter-with-Containers
Microsoft Windows Server Windows Server 2016-Datacenter
Microsoft Windows Server Windows Server 2016-Datacenter-Server-Core
Microsoft Windows Server Windows Server 2016-Datacenter-with-Containers

PUBLICADOR OFERTA SKU
Microsoft Windows Server Windows Server Centro de datos de 2012-R2
Microsoft Windows Server Windows Server Centro de datos de 2012
MicrosoftDynamicsNAV DynamicsNAV 2017
MicrosoftSharePoint MicrosoftSharePointServer 2019
MicrosoftSQLServer SQL2019-WS2016 Enterprise
MicrosoftRServer RServer-WS2016 Enterprise
Navegación por las imágenes

Una manera de encontrar una imagen en una ubicación es mediante la ejecución de los cmdlets Get-
AzVMImagePublisher, Get-AzVMImageOffer y Get-AzVMImageSku en orden:
1. Listado de los publicadores de imágenes.
2. Para un publicador determinado, enumeración de sus ofertas.
3. Para una oferta determinada, enumeración de sus SKU.
Luego, para una SKU seleccionada, ejecute Get-AzVMImage para mostrar las versiones que se van a implementar.
1. Muestre una lista de los publicadores:
$locName="<Azure location, such as West US>"

Get-AzVMImagePublisher -Location $locName | Select PublisherName
2. Rellene el nombre del publicador elegido y haga una lista de las ofertas:
$pubName="<publisher>"
Get-AzVMImageOffer -Location $locName -PublisherName $pubName | Select Offer
3. Rellene el nombre de la oferta elegida y haga una lista de las SKU:
$offerName="<offer>"
Get-AzVMImageSku -Location $locName -PublisherName $pubName -Offer $offerName | Select Skus
4. Rellene el nombre de la SKU elegido y obtenga la versión de imagen:
$skuName="<SKU>"
Get-AzVMImage -Location $locName -PublisherName $pubName -Offer $offerName -Sku $skuName | Select
Version
En la salida del comando Get-AzVMImage , puede seleccionar una imagen de la versión para implementar una
máquina virtual nueva.
En el ejemplo siguiente se muestra la secuencia completa de comandos y sus salidas:
$locName="West US"
Get-AzVMImagePublisher -Location $locName | Select PublisherName
Salida parcial:
PublisherName
-------------
...
abiquo
accedian
accellion
accessdata-group
accops
Acronis
Acronis.Backup
actian-corp
actian_matrix
actifio
activeeon
adgs
advantech
advantech-webaccess
advantys
...
Para el publicador de MicrosoftWindowsServer:
$pubName="MicrosoftWindowsServer"
Get-AzVMImageOffer -Location $locName -PublisherName $pubName | Select Offer
Salida:
Offer
-----
Windows-HUB
WindowsServer
WindowsServerSemiAnnual
Para la oferta de WindowsServer:
$offerName="WindowsServer"
Get-AzVMImageSku -Location $locName -PublisherName $pubName -Offer $offerName | Select Skus
Salida parcial:
Skus
----
2008-R2-SP1
2008-R2-SP1-smalldisk
2012-Datacenter
2012-Datacenter-smalldisk
2012-R2-Datacenter
2012-R2-Datacenter-smalldisk
2016-Datacenter
2016-Datacenter-Server-Core
2016-Datacenter-Server-Core-smalldisk
2016-Datacenter-smalldisk
2016-Datacenter-with-Containers
2016-Datacenter-with-RDSH
2019-Datacenter
2019-Datacenter-Core
2019-Datacenter-Core-smalldisk
2019-Datacenter-Core-with-Containers
...
Luego, para la SKU de 2019 -Datacenter:
$skuName="2019-Datacenter"
Get-AzVMImage -Location $locName -PublisherName $pubName -Offer $offerName -Sku $skuName | Select Version
Ahora puede combinar el publicador, la oferta, la SKU y la versión que se seleccionó en un URN (valores
separados por :). Pase este URN con el parámetro --image al crear una VM con el cmdlet New -AzVM. Puede
reemplazar de forma opcional el número de versión en el URN con "más actualizado" para obtener la versión más
actualizada de la imagen.
Si implementa una máquina virtual con una plantilla de Resource Manager, establecerá los parámetros de imagen
individualmente en las propiedades imageReference . Consulte la referencia de plantilla.
Implementación de una imagen con términos de Marketplace

Algunas imágenes de máquina virtual en Azure Marketplace tienen términos adicionales de licencia y compra que
debe aceptar antes de poder implementarlas mediante programación.
Para implementar una máquina virtual a partir de ese tipo de imagen, deberá aceptar los términos de la imagen y
habilitar la implementación mediante programación. Solo tendrá que hacerlo una vez por suscripción. Luego, cada
vez que implementa una máquina virtual mediante programación a partir de la imagen, también deberá
especificar los parámetros de plan de compra.
En las secciones siguientes se muestra cómo:
Averiguar si una imagen de Marketplace tiene términos de licencia adicionales
Aceptar los términos mediante programación
Proporcionar los parámetros de plan de compra al implementar una máquina virtual mediante programación
Vista de las propiedades del plan
Para ver la información del plan de compra de una imagen, ejecute el cmdlet Get-AzVMImage . Si la propiedad
PurchasePlan de la salida no es null , la imagen tienen términos que debe aceptar antes de la implementación
mediante programación.
Por ejemplo, la imagen Windows Server 2016 Datacenter no tiene términos adicionales, porque la información de
PurchasePlan es null :
$version = "2016.127.20170406"
Get-AzVMImage -Location $locName -PublisherName $pubName -Offer $offerName -Skus $skuName -Version $version
Salida:
Id : /Subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/Providers/Microsoft.Compute/Locations/westus/Publishers/MicrosoftWindowsServer/ArtifactTypes/VMIm
age/Offers/WindowsServer/Skus/2016-Datacenter/Versions/2019.0.20190115
Location : westus
PublisherName : MicrosoftWindowsServer
Offer : WindowsServer
Skus : 2019-Datacenter
Version : 2019.0.20190115
FilterExpression :
Name : 2019.0.20190115
OSDiskImage : {
"operatingSystem": "Windows"
}
PurchasePlan : null
DataDiskImages : []
En el ejemplo siguiente se muestra un comando similar para la imagen Data Science Virtual Machine - Windows
2016 que tiene las propiedades PurchasePlan siguientes: name , product y publisher . Algunas imágenes
también tienen una propiedad promotion code . Para implementar esta imagen, consulte las secciones siguientes
para aceptar los términos y habilitar la implementación mediante programación.
Get-AzVMImage -Location "westus" -PublisherName "microsoft-ads" -Offer "windows-data-science-vm" -Skus

"windows2016" -Version "0.2.02"
Salida:
Id : /Subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/Providers/Microsoft.Compute/Locations/westus/Publishers/microsoft-
ads/ArtifactTypes/VMImage/Offers/windows-data-science-vm/Skus/windows2016/Versions/19.01.14
Location : westus
PublisherName : microsoft-ads
Offer : windows-data-science-vm
Skus : windows2016
Version : 19.01.14
FilterExpression :
Name : 19.01.14
OSDiskImage : {
"operatingSystem": "Windows"
}
PurchasePlan : {
"publisher": "microsoft-ads",
"name": "windows2016",
"product": "windows-data-science-vm"
}
DataDiskImages : []
Aceptación de los términos

Para ver los términos de licencia, use el cmdlet Get-AzMarketplaceterms y pase los parámetros del plan de
compra. La salida proporciona un vínculo a los términos de la imagen de Marketplace y muestra si anteriormente
aceptó los términos. Asegúrese de que todas las letras sean minúsculas en los valores de parámetros.
Get-AzMarketplaceterms -Publisher "microsoft-ads" -Product "windows-data-science-vm" -Name "windows2016"
Salida:
Publisher : microsoft-ads
Product : windows-data-science-vm
Plan : windows2016
LicenseTextLink :
https://storelegalterms.blob.core.windows.net/legalterms/3E5ED_legalterms_MICROSOFT%253a2DADS%253a24WINDOWS%25
3a2DDATA%253a2DSCIENCE%253a2DVM%253a24WINDOWS2016%253a24OC5SKMQOXSED66BBSNTF4XRCS4XLOHP7QMPV54DQU7JCBZWYFP35ID
POWTUKXUC7ZAG7W6ZMDD6NHWNKUIVSYBZUTZ245F44SU5AD7Q.txt
PrivacyPolicyLink : https://www.microsoft.com/EN-US/privacystatement/OnlineServices/Default.aspx
Signature :
2UMWH6PHSAIM4U22HXPXW25AL2NHUJ7Y7GRV27EBL6SUIDURGMYG6IIDO3P47FFIBBDFHZHSQTR7PNK6VIIRYJRQ3WXSE6BTNUNENXA
Accepted : False
Signdate : 1/25/2019 7:43:00 PM
Use el cmdlet Set-AzMarketplaceterms para aceptar o rechazar los términos. Solo debe aceptar los términos una
vez por suscripción para la imagen. Asegúrese de que todas las letras sean minúsculas en los valores de
parámetros.
$agreementTerms=Get-AzMarketplaceterms -Publisher "microsoft-ads" -Product "windows-data-science-vm" -Name

"windows2016"
Set-AzMarketplaceTerms -Publisher "microsoft-ads" -Product "windows-data-science-vm" -Name "windows2016" -

Terms $agreementTerms -Accept
Salida:
Publisher : microsoft-ads
Product : windows-data-science-vm
Plan : windows2016
LicenseTextLink :
https://storelegalterms.blob.core.windows.net/legalterms/3E5ED_legalterms_MICROSOFT%253a2DADS%253a24WINDOWS%25
3a2DDATA%253a2DSCIENCE%253a2DV
M%253a24WINDOWS2016%253a24OC5SKMQOXSED66BBSNTF4XRCS4XLOHP7QMPV54DQU7JCBZWYFP35IDPOWTUKXUC7ZAG7W6ZMDD6NHWNKUIVS
YBZUTZ245F44SU5AD7Q.txt
PrivacyPolicyLink : https://www.microsoft.com/EN-US/privacystatement/OnlineServices/Default.aspx
Signature :
XXXXXXK3MNJ5SROEG2BYDA2YGECU33GXTD3UFPLPC4BAVKAUL3PDYL3KBKBLG4ZCDJZVNSA7KJWTGMDSYDD6KRLV3LV274DLBXXXXXX
Accepted : True
Signdate : 2/23/2018 7:49:31 PM
Implementación mediante los parámetros del plan de compra

Después de aceptar los términos de una imagen, puede implementar una máquina virtual en esa suscripción.
Como se muestra en el fragmento de código siguiente, use el cmdlet Set-AzVMPlan para establecer la
información de plan de Marketplace para el objeto de la VM. Para que un script completo cree la configuración de
red para la máquina virtual y complete la implementación, consulte los ejemplos de script de PowerShell.
...
$vmConfig = New-AzVMConfig -VMName "myVM" -VMSize Standard_D1
# Set the Marketplace plan information
$publisherName = "microsoft-ads"
$productName = "windows-data-science-vm"
$planName = "windows2016"
$vmConfig = Set-AzVMPlan -VM $vmConfig -Publisher $publisherName -Product $productName -Name $planName
$cred=Get-Credential
$vmConfig = Set-AzVMOperatingSystem -Windows -VM $vmConfig -ComputerName "myVM" -Credential $cred
# Set the Marketplace image
$offerName = "windows-data-science-vm"
$skuName = "windows2016"
$version = "19.01.14"
$vmConfig = Set-AzVMSourceImage -VM $vmConfig -PublisherName $publisherName -Offer $offerName -Skus $skuName -
Version $version
...
Luego, la configuración de la VM se pasará junto con los objetos de configuración de red al cmdlet New-AzVM .
Pasos siguientes
Para crear una máquina virtual rápidamente con el cmdlet New-AzVM mediante información de imagen básica,
consulte Creación de una máquina virtual Windows con PowerShell.
Consulte un ejemplo de script de PowerShell para crear una máquina virtual completamente configurada.
Preparación de un VHD o un VHDX de Windows
antes de cargarlo en Azure
Antes de cargar una máquina virtual Windows desde un entorno local en Azure, debe preparar el disco duro
virtual (VHD o VHDX). Azure admite máquinas virtuales de generación 1 y de generación 2 que estén en el
formato de archivo VHD y tengan un disco de tamaño fijo. El tamaño máximo permitido para los discos duros
virtuales es de 1023 GB.
En una máquina virtual de generación 1, un sistema de archivos VHDX se puede convertir a VHD. También se
puede convertir un disco de expansión dinámica en un disco de tamaño fijo. Sin embargo, no puede cambiar la
generación de una máquina virtual. Para más información, vea ¿Debería crear una máquina virtual de
generación 1 o 2 en Hyper-V? y Compatibilidad de Azure con máquinas virtuales de generación 2 (versión
preliminar).
Para información sobre la directiva de soporte de software de servidor de Microsoft ejecutado en Azure, vea
Soporte técnico del software de servidor de Microsoft para máquinas virtuales de Microsoft Azure.
NOTE
Las instrucciones de este artículo se aplican a:
1. La versión de Windows Server 2008 R2 de 64 bits y versiones posteriores de los sistemas operativos de
Windows Server. Para más información sobre cómo ejecutar un sistema operativo de 32 bits en Azure, vea
Compatibilidad de sistemas operativos de 32 bits en máquinas virtuales de Azure.
2. Si se va a usar una herramienta de recuperación ante desastres para migrar la carga de trabajo, como Azure Site
Recovery o Azure Migrate, sigue siendo necesario realizar este proceso y seguirlo en el sistema operativo invitado
para preparar la imagen antes de la migración.
Conversión de un disco virtual en un disco de tamaño fijo y VHD

Si necesita convertir el disco virtual al formato requerido para Azure, utilice uno de los métodos de esta
sección:
1. Cree una copia de seguridad de la máquina virtual antes de ejecutar el proceso de conversión del disco
virtual.
2. Asegúrese de que el disco duro virtual de Windows funciona correctamente en el servidor local.
Resuelva los errores dentro de la propia máquina virtual antes de intentar la conversión o la carga en
Azure.
3. Con respecto al tamaño del disco duro virtual:
a. En Azure, todos los discos duros virtuales deben tener un tamaño virtual alineado con 1 MB. Al
convertir un disco sin procesar en un disco duro virtual, tiene que asegurarse de que su tamaño
es un múltiplo de 1 MB antes de la conversión. Las fracciones de un megabyte provocarán
errores al crear imágenes a partir del disco duro virtual cargado.
b. El tamaño máximo permitido del disco duro virtual del SO es de 2 TB.
Después de convertir el disco, cree una máquina virtual que use dicho disco. Inicie la máquina virtual e inicie
sesión en ella para prepararla para cargarla.
Uso de Administrador de Hyper-V para convertir el disco
1. Abra el Administrador de Hyper-V y seleccione el equipo local de la izquierda. En el menú situado sobre la
lista de equipos, seleccione Acción > Editar disco.
2. En la página Localizar disco duro virtual, localice y seleccione el disco virtual.
3. En la página Elegir acción, seleccione Convertir > Siguiente.
4. Si necesita realizar la conversión desde VHDX, seleccione VHD > Siguiente.
5. Si necesita realizar la conversión desde un disco de expansión dinámica, seleccione Tamaño fijo >
Siguiente.
6. Localice y seleccione una ruta de acceso para guardar el nuevo archivo VHD en ella.
7. Seleccione Finalizar.
NOTE
Use una sesión de PowerShell con privilegios elevados para ejecutar los comandos de este artículo.
Uso de PowerShell para convertir el disco

Puede convertir un disco virtual mediante el comando Convert-VHD en Windows PowerShell. Seleccione
Ejecutar como administrador al iniciar PowerShell.
Con el siguiente comando de ejemplo, el disco se convierte de VHDX a VHD. Este comando convierte también
un disco de expansión dinámica en un disco de tamaño fijo.
Convert-VHD –Path c:\test\MY-VM.vhdx –DestinationPath c:\test\MY-NEW-VM.vhd -VHDType Fixed
En este comando, reemplace el valor de -Path por la ruta de acceso del disco duro virtual que quiera convertir.
Reemplace el valor de -DestinationPath por la nueva ruta de acceso y el nombre del disco convertido.
Conversión del formato de disco VMDK de VMware
Si tiene una imagen de máquina virtual de Windows en formato de archivo VMDK, use Microsoft Virtual
Machine Converter para convertirla en un disco duro virtual. Para más información, vea Cómo convertir un
VMDK de VMWare a VHD de Hyper-V.
Establecimiento de configuraciones de Windows para Azure

En la máquina virtual que tenga previsto cargar en Azure, ejecute los siguientes comandos en una ventana del
símbolo del sistema con privilegios elevados:
1. Quite cualquier ruta estática persistente de la tabla de enrutamiento:
Para ver la tabla de rutas, ejecute route print en el símbolo del sistema.
Consulte las secciones Persistence Routes . Si hay una ruta persistente, use el comando
route delete para quitarla.
2. Quite al proxy WinHTTP:
netsh winhttp reset proxy
Si es necesario que la máquina virtual funcione con algún proxy concreto, agregue una excepción de
proxy a la dirección IP de Azure (168.63.129.16), de forma que la máquina virtual tenga conectividad
con Azure:
$proxyAddress="<your proxy server>"
$proxyBypassList="<your list of bypasses>;168.63.129.16"
netsh winhttp set proxy $proxyAddress $proxyBypassList
3. Establezca la directiva SAN del disco en Onlineall :
diskpart
En la ventana del símbolo del sistema abierta, escriba los comandos siguientes:
san policy=onlineall
exit
4. Establezca la Hora universal coordinada (UTC ) para Windows. Establezca también el tipo de inicio del
servicio Hora de Windows ( w32time ) en Automatic :
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\TimeZoneInformation' -Name

"RealTimeIsUniversal" -Value 1 -Type DWord -Force
Set-Service -Name w32time -StartupType Automatic
5. Establezca el perfil de energía en alto rendimiento:
powercfg /setactive SCHEME_MIN
6. Asegúrese de que las variables de entorno TEMP y TMP están establecidos en sus valores
predeterminados:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' -Name

"TEMP" -Value "%SystemRoot%\TEMP" -Type ExpandString -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' -Name

"TMP" -Value "%SystemRoot%\TEMP" -Type ExpandString -Force
Comprobación de los servicios de Windows

Asegúrese de que cada uno de los siguientes servicios de Windows está establecido en los valores
predeterminados de Windows. Estos servicios son lo mínimo que debe configurarse para garantizar la
conectividad de las máquinas virtuales. Para restablecer la configuración de inicio, ejecute los siguientes
comandos:
Get-Service -Name bfe | Where-Object { $_.StartType -ne 'Automatic' } | Set-Service -StartupType
'Automatic'
Get-Service -Name dhcp | Where-Object { $_.StartType -ne 'Automatic' } | Set-Service -StartupType
'Automatic'
Get-Service -Name dnscache | Where-Object { $_.StartType -ne 'Automatic' } | Set-Service -StartupType
'Automatic'
Get-Service -Name IKEEXT | Where-Object { $_.StartType -ne 'Automatic' } | Set-Service -StartupType
'Automatic'
Get-Service -Name iphlpsvc | Where-Object { $_.StartType -ne 'Automatic' } | Set-Service -StartupType
'Automatic'
Get-Service -Name netlogon | Where-Object { $_.StartType -ne 'Manual' } | Set-Service -StartupType 'Manual'
Get-Service -Name netman | Where-Object { $_.StartType -ne 'Manual' } | Set-Service -StartupType 'Manual'
Get-Service -Name nsi | Where-Object { $_.StartType -ne 'Automatic' } | Set-Service -StartupType
'Automatic'
Get-Service -Name TermService | Where-Object { $_.StartType -ne 'Manual' } | Set-Service -StartupType
'Manual'
Get-Service -Name MpsSvc | Where-Object { $_.StartType -ne 'Automatic' } | Set-Service -StartupType
'Automatic'
Get-Service -Name RemoteRegistry | Where-Object { $_.StartType -ne 'Automatic' } | Set-Service -StartupType
'Automatic'
Actualización de la configuración del Registro de Escritorio remoto

Asegúrese de que la siguiente configuración está establecida correctamente para la conexión remota:
NOTE
Puede que reciba un mensaje de error al ejecutar
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services -Name <object
name> -Value <value>
. Puede omitir este mensaje sin problemas. Solo significa que el dominio no obliga a esa configuración a aceptar un
objeto de directiva de grupo.
1. Protocolo de escritorio remoto (RDP ) está habilitado:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name

"fDenyTSConnections" -Value 0 -Type DWord -Force
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' -Name

"fDenyTSConnections" -Value 0 -Type DWord -Force
2. El puerto de RDP está configurado correctamente. El puerto predeterminado es 3389:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp'

-Name "PortNumber" -Value 3389 -Type DWord -Force
Al implementar una máquina virtual, las reglas predeterminadas se crean en el puerto 3389. Si quiere
cambiar el número de puerto, hágalo una vez implementada la máquina virtual en Azure.
3. El agente de escucha está escuchando en todas las interfaces de red:

-Name "LanAdapter" -Value 0 -Type DWord -Force
4. Configure el modo Autenticación a nivel de red (NLA) para las conexiones RDP:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'
-Name "UserAuthentication" -Value 1 -Type DWord -Force

-Name "SecurityLayer" -Value 1 -Type DWord -Force

-Name "fAllowSecProtocolNegotiation" -Value 1 -Type DWord -Force
5. Establezca el valor de conexión persistente:

"KeepAliveEnable" -Value 1 -Type DWord -Force
"KeepAliveInterval" -Value 1 -Type DWord -Force
-Name "KeepAliveTimeout" -Value 1 -Type DWord -Force
6. Vuelva a conectarse:

"fDisableAutoReconnect" -Value 0 -Type DWord -Force
-Name "fInheritReconnectSame" -Value 1 -Type DWord -Force
-Name "fReconnectSame" -Value 0 -Type DWord -Force
7. Limite el número de conexiones simultáneas:

-Name "MaxInstanceCount" -Value 4294967295 -Type DWord -Force
8. Quite cualquier certificado autofirmado que pueda haber enlazado al agente de escucha del Protocolo
de escritorio remoto:
if ((Get-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-

Tcp').Property -contains "SSLCertificateSHA1Hash")
{
Remove-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal
Server\WinStations\RDP-Tcp' -Name "SSLCertificateSHA1Hash" -Force
}
Este código garantiza que puede se conectar al principio, al implementar la máquina virtual. Si necesita
revisar esto más adelante, puede hacerlo una vez implementada la máquina virtual en Azure.
9. Si la máquina virtual va a formar parte de un dominio, compruebe las siguientes directivas para
asegurarse de que la configuración anterior no se revierte.
OBJETIVO DIRECTIVA VALOR
RDP está habilitado Configuración del Permitir a los usuarios conectarse

equipo\Directivas\Configuración de de forma remota desde el Escritorio
Windows\Plantillas administrativas\ remoto
Componentes\Servicios de
Escritorio remoto\Host de sesión de
Escritorio remoto\Conexiones
Directiva de grupo de NLA Configuración\Plantillas Requerir la autenticación del usuario

administrativas\Componentes\Servi para las conexiones remotas
cios de Escritorio remoto\Host de mediante Autenticación a nivel de
sesión de Escritorio red
remoto\Seguridad
Configuración de configuración Configuración del Configurar el intervalo de conexión

persistente equipo\Directivas\Configuración de persistente
Windows\Plantillas administrativas\
Componentes Windows\Servicios
de Escritorio remoto\Host de sesión
de Escritorio remoto\Conexiones
Configuración de reconexión Configuración del Reconectar automáticamente

equipo\Directivas\Configuración de
Configuración de número limitado Configuración del Limitar el número de conexiones

de conexiones equipo\Directivas\Configuración de
Configuración de reglas de firewall de Windows

1. Active Firewall de Windows en los tres perfiles (dominio, estándar y público):
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True
2. Ejecute el comando siguiente en PowerShell para permitir WinRM mediante los tres perfiles de firewall
(dominio, privado y público) y habilitar el servicio remoto de PowerShell:
Enable-PSRemoting -Force
Set-NetFirewallRule -DisplayName "Windows Remote Management (HTTP-In)" -Enabled True
3. Habilite las siguientes reglas de firewall para permitir el tráfico RDP:
Set-NetFirewallRule -DisplayGroup "Remote Desktop" -Enabled True
4. Habilite la regla de uso compartido de archivos e impresoras para que la máquina virtual pueda
responder a un comando ping dentro de la red virtual:
Set-NetFirewallRule -DisplayName "File and Printer Sharing (Echo Request - ICMPv4-In)" -Enabled True
5. Si la máquina virtual va a formar parte de un dominio, compruebe las siguientes directivas de Azure AD
para asegurarse de que la configuración anterior no se revierte.
Habilitar los perfiles de Firewall de Configuración del Proteger todas las conexiones de
Windows equipo\Directivas\Configuración de red
Windows\Plantillas
administrativas\Red\Conexión de
red\Firewall de Windows\Perfil de
dominio\Firewall de Window
Habilitar RDP Configuración del Permitir excepciones de Escritorio

equipo\Directivas\Configuración de remoto entrantes
Windows\Plantillas
Configuración del Permitir excepciones de Escritorio

equipo\Directivas\Configuración de remoto entrantes
Windows\Plantillas
red\Firewall de Windows\Perfil
estándar\Firewall de Windows
Habilitar ICMP-V4 Configuración del Permitir excepciones de ICMP

Windows\Plantillas
Configuración del Permitir excepciones de ICMP

Windows\Plantillas
red\Firewall de Windows\Perfil
estándar\Firewall de Windows
Comprobación de la máquina virtual

Asegúrese de que la máquina virtual tiene un estado correcto, es segura y está accesible desde RDP:
1. Para garantizar que el disco es coherente y está en buen estado, compruebe el disco en el próximo
reinicio de máquina virtual:
Chkdsk /f
Asegúrese de que el informe muestra un disco limpio y en buen estado.

2. Establezca la configuración de datos de la configuración de arranque (BCD ).
NOTE
Use una ventana de PowerShell con privilegios elevados para ejecutar estos comandos.
bcdedit /set "{bootmgr}" integrityservices enable
bcdedit /set "{default}" device partition=C:
bcdedit /set "{default}" integrityservices enable
bcdedit /set "{default}" recoveryenabled Off
bcdedit /set "{default}" osdevice partition=C:
bcdedit /set "{default}" bootstatuspolicy IgnoreAllFailures
#Enable Serial Console Feature

bcdedit /set "{bootmgr}" displaybootmenu yes
bcdedit /set "{bootmgr}" timeout 5
bcdedit /set "{bootmgr}" bootems yes
bcdedit /ems "{current}" ON
bcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200
3. El registro de volcado de memoria puede ser útil para solucionar problemas de bloqueo de Windows.
Habilite la colección de registros de volcado de memoria:
# Set up the guest OS to collect a kernel dump on an OS crash event

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name CrashDumpEnabled
-Type DWord -Force -Value 2
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name DumpFile -Type
ExpandString -Force -Value "%SystemRoot%\MEMORY.DMP"
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name NMICrashDump -
Type DWord -Force -Value 1
# Set up the guest OS to collect user mode dumps on a service crash event
$key = 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps'
if ((Test-Path -Path $key) -eq $false) {(New-Item -Path 'HKLM:\SOFTWARE\Microsoft\Windows\Windows
Error Reporting' -Name LocalDumps)}
New-ItemProperty -Path $key -Name DumpFolder -Type ExpandString -Force -Value "c:\CrashDumps"
New-ItemProperty -Path $key -Name CrashCount -Type DWord -Force -Value 10
New-ItemProperty -Path $key -Name DumpType -Type DWord -Force -Value 2
Set-Service -Name WerSvc -StartupType Manual
4. Compruebe que el repositorio de Instrumental de administración de Windows (WMI) es coherente:
winmgmt /verifyrepository
Si el repositorio está dañado, consulte WMI: daños en el repositorio, o no.

5. Asegúrese de que ninguna otra aplicación está usando el puerto 3389. Este puerto se usa para el
servicio RDP en Azure. Para ver qué puertos se usan en la máquina virtual, ejecute netstat -anob :
netstat -anob
6. Para cargar un VHD de Windows que sea un controlador de dominio:

Siga estos pasos adicionales para preparar el disco.
Asegúrese de que conoce la contraseña de Modo de restauración de servicios de directorio
(DSRM ), por si tiene que iniciar la máquina virtual en DSRM en algún momento. Para más
información, vea Establecer una contraseña de DSRM.
7. Asegúrese de que conoce la cuenta predefinida de administrador y la contraseña. Es posible que quiera
restablecer la contraseña de administrador local actual y asegurarse de que puede usar esta cuenta para
iniciar sesión en Windows mediante la conexión RDP. Este permiso de acceso se controla mediante el
objeto de directiva de grupo "Permitir inicio de sesión a través de Servicios de Escritorio remoto". Puede
ver este objeto en el Editor de directivas de grupo local, aquí:
Configuración del equipo\Configuración de Windows\Configuración de seguridad\Directivas
locales\Asignación de derechos de usuario
8. Compruebe las siguientes directivas de Azure AD para asegurarse de que no bloquea el acceso de RDP
a través de RDP ni desde la red:
locales\Asignación de derechos de usuario\Denegar el acceso a este equipo desde la red
locales\Asignación de derechos de usuario\Denegar inicio de sesión a través de Servicios de
Escritorio remoto
9. Compruebe la siguiente directiva de Azure AD para asegurarse de que no quita ninguna de las cuentas
de acceso obligatorias:
locales\Asignación de derechos de usuario\Acceder a este equipo desde la red
En la directiva deben aparecer los siguientes grupos:
Administradores
Operadores de copias de seguridad
Todos
Usuarios
10. Reinicie la máquina virtual para asegurarse de que Windows sigue funcionando correctamente y puede
conectarse a ella a través de RDP. Llegado este punto, puede que quiera crear una máquina virtual en la
instancia de Hyper-V local para asegurarse de que la máquina virtual se inicia completamente. Tras ello,
realice pruebas para asegurarse de que se puede acceder a la máquina virtual a través de RDP.
11. Quite los filtros extra de Interfaz de controlador de transporte (TDI). Por ejemplo, quite el software que
analice paquetes TCP o firewalls adicionales. Si necesita revisar esto más adelante, puede hacerlo una
vez implementada la máquina virtual en Azure.
12. Desinstale cualquier otro software de terceros o controlador relacionado con componentes físicos, o
cualquier otra tecnología de virtualización.
Instalación de actualizaciones de Windows
Lo ideal es mantener la máquina actualizada en el nivel de revisión pero, si no es posible, asegúrese de que las
siguientes actualizaciones están instaladas:
WINDOW WINDOW WINDOW

WINDOW S 10 S 10 S 10
S 7 SP1, WINDOW WINDOW V1607, V1709, V1803,
WINDOW S 8, S 8.1, WINDOW WINDOW WINDOW
S SERVER WINDOW WINDOW S SERVER WINDOW S SERVER S SERVER
COMPONE 2008 R2 S S SERVER S SERVER 2016 V160 S 10 2016 V170 2016 V180
NTE BINARY P1 2012 2012 R2 7 V1703 9 3
Storage disk.sys 6.1.7601. 6.2.9200. 6.3.9600. - - - -

23403 - 17638 / 18203 -
KB31255 6.2.9200. KB31370
74 21757 - 61
KB31370
61
NTE BINARY P1 2012 2012 R2 7 V1703 9 3
storport.s 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

ys 23403 - 17188 / 18573 - 93.1358 63.332
KB31255 6.2.9200. KB40227 -
74 21306 - 26 KB40227
KB30184 15
89
ntfs.sys 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

23403 - 17623 / 18654 - 93.1198 63.447
KB31255 6.2.9200. KB40227 -
74 21743 - 26 KB40227
KB31212 15
55
Iologmsg. 6.1.7601. 6.2.9200. - - - - -

dll 23403 - 16384 -
KB31255 KB29953
74 87
Classpnp. 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 - - -

sys 23403 - 17061 / 18334 - 93.953 -
KB31255 6.2.9200. KB31726 KB40227
74 21180 - 14 15
KB29953
87
Volsnap.s 6.1.7601. 6.2.9200. 6.3.9600. - 10.0.150 - -

ys 23403 - 17047 / 18265 - 63.0
KB31255 6.2.9200. KB31453
74 21165 - 84
KB29753
31
partmgr.s 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

ys 23403 - 16681 - 17401 - 93.953 - 63.0
KB31255 KB28771 KB30008 KB40227
74 14 50 15
volmgr.sy 10.0.150 - -
s 63.0
Volmgrx.s 6.1.7601. - - - 10.0.150 - -

ys 23403 - 63.0
KB31255
74
Msiscsi.sy 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

s 23403 - 21006 - 18624 - 93.1066 63.447
KB31255 KB29551 KB40227 -
74 63 26 KB40227
15
NTE BINARY P1 2012 2012 R2 7 V1703 9 3
Msdsm.s 6.1.7601. 6.2.9200. 6.3.9600. - - - -

ys 23403 - 21474 - 18592 -
KB31255 KB30461 KB40227
74 01 26
Mpio.sys 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 - - -

23403 - 21190 - 18616 - 93.1198
KB31255 KB30461 KB40227 -
74 01 26 KB40227
15
vmstorfl.s 6.3.9600. 6.3.9600. 6.3.9600. 10.0.143 10.0.150 10.0.162 -

ys 18907 - 18080 - 18907 - 93.2007 63.850 - 99.371 -
KB40726 KB30631 KB40726 - KB43454 KB43454
50 09 50 KB43454 19 20
18
Fveapi.dll 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 - - -

23311 - 20930 - 18294 - 93.576 -
KB31255 KB29302 KB31726 KB40227
74 44 14 15
Fveapibas 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 - - -

e.dll 23403 - 20930 - 17415 - 93.206 -
KB31255 KB29302 KB31726 KB40227
74 44 14 15
Red netvsc.sy - - - 10.0.143 10.0.150 - -

s 93.1198 63.250 -
- KB40200
KB40227 01
15
mrxsmb1 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

0.sys 23816 - 22108 - 18603 - 93.479 - 63.483
KB40227 KB40227 KB40227 KB40227
22 24 26 15
mrxsmb2 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

0.sys 23816 - 21548 - 18586 - 93.953 - 63.483
KB40227 KB40227 KB40227 KB40227
22 24 26 15
mrxsmb.s 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

ys 23816 - 22074 - 18586 - 93.953 - 63.0
KB40227 KB40227 KB40227 KB40227
22 24 26 15
NTE BINARY P1 2012 2012 R2 7 V1703 9 3
tcpip.sys 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

23761 - 22070 - 18478 - 93.1358 63.447
KB40227 KB40227 KB40227 -
22 24 26 KB40227
15
http.sys 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

23403 - 17285 - 18574 - 93.251 - 63.483
KB31255 KB30425 KB40227 KB40227
74 53 26 15
vmswitch. 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

sys 23727 - 22117 - 18654 - 93.1358 63.138
KB40227 KB40227 KB40227 -
19 24 26 KB40227
15
Core ntoskrnl.e 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

xe 23807 - 22170 - 18696 - 93.1358 63.483
KB40227 KB40227 KB40227 -
19 18 26 KB40227
15
Servicios rdpcorets 6.2.9200. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

de .dll 21506 - 22104 - 18619 - 93.1198 63.0
Escritorio KB40227 KB40227 KB40227 -
remoto 19 24 26 KB40227
15
termsrv.d 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

ll 23403 - 17048 - 17415 - 93.0 - 63.0
KB31255 KB29735 KB30008 KB40227
74 01 50 15
termdd.s 6.1.7601. - - - - - -
ys 23403 -
KB31255
74
win32k.sy 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 - - -

s 23807 - 22168 - 18698 - 93.594 -
KB40227 KB40227 KB40227 KB40227
19 18 26 15
rdpdd.dll 6.1.7601. - - - - - -
23403 -
KB31255
74
NTE BINARY P1 2012 2012 R2 7 V1703 9 3
rdpwd.sy 6.1.7601. - - - - - -
s 23403 -
KB31255
74
Segurida MS17- KB40122 KB40122 KB40122 KB40126 KB40126 - -

d 010 12 13 13 06 06
KB40122 KB40131 KB40131 - -

16 98 98
KB40122 KB40122 KB40122 KB40134 KB40134 - -

15 14 16 29 29
KB40122 KB40134 KB40134 - -

17 29 29
CVE- KB41037 KB41037 KB41037 KB41037 KB41037 KB41037 KB41037

2018- 18 30 25 23 31 27 21
0886
KB41037 KB41037 KB41037

12 26 15
NOTE
Para evitar un reinicio accidental durante el aprovisionamiento de la máquina virtual, es aconsejable asegurarse de que
todas las instalaciones de Windows Update han finalizado y de que no hay actualizaciones pendientes. Una manera de
hacerlo es instalar todas las actualizaciones de Windows posibles y reiniciar una vez antes de ejecutar el comando
Sysprep.
Determinar cuándo usar Sysprep

Herramienta de preparación del sistema (Sysprep) es un proceso que se puede ejecutar para restablecer una
instalación de Windows. Sysprep proporciona una experiencia original, al eliminar todos los datos personales y
restablecer varios componentes.
Sysprep se suele ejecutar para crear una plantilla desde la que implementar muchas otras máquinas virtuales
que tengan una configuración específica. Esta plantilla se conoce como imagen generalizada.
Si lo que quiere es crear una sola máquina virtual desde un disco, no tiene que usar Sysprep, sino crear la
máquina virtual desde una imagen especializada. Para más información sobre cómo crear una máquina virtual
desde un disco especializado, vea:
Creación de una máquina virtual a partir de un disco especializado
Create a VM from a specialized VHD disk (Creación de una máquina virtual a partir de un disco duro
virtual especializado)
Si desea crear una imagen generalizada, debe ejecutar Sysprep. Para información, vea Uso de Sysprep:
Introducción.
No todos los roles o aplicaciones instalados en un equipo basado en Windows admiten estas imágenes
generalizadas; por lo tanto, antes de ejecutar este procedimiento, asegúrese de que Sysprep admite el rol del
equipo. Para más información, consulte Sysprep Support for Server Roles (Compatibilidad de Sysprep con
roles de servidor).
Generalización de un VHD
NOTE
Después de ejecutar sysprep.exe en los pasos siguientes, desactive la máquina virtual. No vuelva a activarla hasta que
cree una imagen de ella en Azure.
1. Inicie sesión en la máquina virtual Windows.

2. Ejecute Símbolo del sistema como administrador.
3. Cambie el directorio a %windir%\system32\sysprep . A continuación, ejecute sysprep.exe .
asegúrese de que la casilla Generalizar está activada.
5. En Opciones de apagado, seleccione Apagar.

6. Seleccione Aceptar.
7. Cuando Sysprep finalice, apague la máquina virtual. No use Reiniciar para apagar la máquina virtual.
Ahora el disco duro virtual está listo para cargarse. Para más información sobre cómo crear una máquina
virtual desde un disco generalizado, vea Carga de un VHD generalizado en Azure para crear una máquina
virtual nueva.
NOTE
No se admite un archivo unattend.xml personalizado, pero sí la propiedad additionalUnattendContent , que solo
proporciona compatibilidad limitada para agregar las opciones de microsoft-windows-shell-setup en el archivo
unattend.xml que utiliza el agente de aprovisionamiento de Azure. Por ejemplo, puede usar additionalUnattendContent
para agregar FirstLogonCommands y LogonCommands. Para más información, vea el ejemplo de FirstLogonCommands
de additionalUnattendContent.
Completar las configuraciones recomendadas
Los siguientes valores de configuración no afectan a la carga de discos duros virtuales. Sin embargo, se
recomienda firmemente que los configure.
Instale el agente de máquina virtual de Azure. A continuación, puede habilitar las extensiones de
máquina virtual. Las extensiones de máquina virtual implementan la mayor parte de la funcionalidad
crítica que es posible que quiera usar con las máquinas virtuales. Necesitará estas extensiones, por
ejemplo, para restablecer contraseñas o configurar RDP. Para más información, vea Información general
sobre el agente de la máquina virtual de Azure.
Después de crear la máquina virtual en Azure, recomendamos que ponga el archivo de paginación en el
volumen de unidad temporal para mejorar el rendimiento. Puede configurar la ubicación de archivos
del siguiente modo:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management' -

Name "PagingFiles" -Value "D:\pagefile.sys" -Type MultiString -Force
Si hay un disco de datos conectado a la máquina virtual, la letra de unidad del volumen de unidad
temporal suele ser D. Esta designación podría ser diferente, dependiendo de la configuración y del
número de unidades disponibles.
Se recomienda deshabilitar los bloqueadores de script que pueda incluir el software antivirus,
Podrían interferir y bloquear los scripts del agente de aprovisionamiento de Windows que se
ejecutan al implementar una nueva máquina virtual desde la imagen.
Pasos siguientes
Carga de una imagen de máquina virtual de Windows en Azure para implementaciones de Resource
Manager
Solución de problemas de activación de máquinas virtuales Windows de Azure
Captura de una imagen administrada de una
máquina virtual generalizada en Azure
Se puede crear un recurso de imagen administrado a partir de una máquina virtual (VM ) generalizada que se
almacena como un disco administrado o como un disco no administrado en una cuenta de almacenamiento. A
partir de ese momento, la imagen se puede utilizar para crear varias máquinas virtuales. Para obtener
información sobre cómo se facturan las imágenes administradas, consulte Precios de Managed Disks.
Generalización de VM con Windows mediante Sysprep

Sysprep elimina toda la información de seguridad y de la cuenta personal y luego prepara la máquina para usarse
como imagen. Para más información acerca de Sysprep, consulte la Introducción a Sysprep.
Asegúrese de que los roles de servidor que se ejecutan en la máquina sean compatibles con Sysprep. Para más
información, consulte Compatibilidad de Sysprep con roles de servidor y Escenarios no admitidos.
IMPORTANT
Una vez que se ha ejecutado sysprep en una máquina virtual, se considera generalizada y no se puede reiniciar. El proceso
de generalización de una máquina virtual no es reversible. Si necesita mantener el funcionamiento original de la máquina
virtual, debe crear una copia de la máquina virtual y generalizar la copia.
Si tiene pensado ejecutar Sysprep antes de cargar el disco duro virtual (VHD) en Azure por primera vez, asegúrese de que
tiene preparada la máquina virtual.
Para generalizar la máquina virtual de Windows, siga estos pasos:

1. Inicie sesión en la máquina virtual Windows.
2. Abra una ventana de símbolo del sistema como administrador. Cambie el directorio a
%windir%\system32\sysprep, y, después, ejecute sysprep.exe .
active la casilla Generalizar.
TIP
Opcional Use DISM para optimizar la imagen y reducir el tiempo de arranque de la máquina virtual.
Para optimizar la imagen, monte el disco duro virtual; para ello, haga doble clic en él en el Explorador de Windows y, a
continuación, ejecute DISM con el parámetro /optimize-image .
DISM /image:D:\ /optimize-image /boot
D: es la ruta de acceso del VHD montado.

La ejecución de DISM /optimize-image debe ser la última modificación que realice en el disco duro virtual. Si realiza
cambios en el disco duro virtual antes de la implementación, tendrá que volver a ejecutar DISM /optimize-image .
Creación de una imagen administrada en el portal

2. En el menú de la izquierda, seleccione Máquinas virtuales y seleccione la máquina virtual de la lista.
3. En la página Máquina virtual de la máquina virtual, en el menú superior, seleccione Capturar.
Aparece la página Crear imagen.
4. En Nombre, acepte el nombre con que se rellena el espacio previamente o escriba un nombre que le
gustaría que se usara para la imagen.
5. En Grupo de recursos, seleccione Crear nuevo y escriba un nombre, o elija Usar existente y seleccione
en la lista desplegable el grupo de recursos que desea utilizar.
6. Si desea eliminar la máquina virtual de origen tras haberse creado la imagen, seleccione Eliminar
automáticamente esta máquina virtual después de crear la imagen.
7. Si desea tener la posibilidad de usar la imagen en cualquier zona de disponibilidad, seleccione Activar
para Resistencia de zona.
8. Seleccione Crear para crear la imagen.
9. Después de crear la imagen, esta aparecerá como un recurso Imagen en la lista de recursos del grupo de
recursos.
Creación de una imagen de una VM mediante PowerShell

Crear una imagen directamente desde la VM garantiza que la imagen incluya todos los discos asociados a la VM,
incluido el disco del SO y todos los discos de datos. En este ejemplo se muestra cómo crear una imagen
administrada a partir de una máquina virtual que utiliza discos administrados.
Antes de comenzar, asegúrese de que tiene la última versión del módulo de Azure PowerShell. Para buscar la
versión, ejecute Get-Module -ListAvailable Az en PowerShell. Si tiene que actualizar, consulte Install Azure
PowerShell on Windows with PowerShellGet (Instalación de Azure PowerShell en Windows con PowerShellGet).
Si PowerShell se ejecuta localmente, ejecute Connect-AzAccount para crear una conexión con Azure.
NOTE
Si desea almacenar la imagen en un almacenamiento con redundancia de zona, debe crearla en una región que admita
zonas de disponibilidad e incluir el parámetro -ZoneResilient en la configuración de la imagen (comando
New-AzImageConfig ).
Para crear una imagen de VM, siga estos pasos:

1. Cree algunas variables.
$vmName = "myVM"
$location = "EastUS"
$imageName = "myImage"
2. Asegúrese de que la VM se ha desasignado.
Stop-AzVM -ResourceGroupName $rgName -Name $vmName -Force
3. Establezca el estado de la máquina virtual en Generalizado.
Set-AzVm -ResourceGroupName $rgName -Name $vmName -Generalized
4. Obtenga la máquina virtual.
5. Cree la configuración de la imagen.
$image = New-AzImageConfig -Location $location -SourceVirtualMachineId $vm.Id
6. Cree la imagen.
New-AzImage -Image $image -ImageName $imageName -ResourceGroupName $rgName
Creación de una imagen a partir de un disco administrado mediante

PowerShell
Si desea crear una imagen de solo el disco del SO, especifique el identificador del disco administrado como disco
del SO:
$vmName = "myVM"
2. Obtenga la máquina virtual.

$vm = Get-AzVm -Name $vmName -ResourceGroupName $rgName
3. Obtenga el id. del disco administrado.
$diskID = $vm.StorageProfile.OsDisk.ManagedDisk.Id

$imageConfig = Set-AzImageOsDisk -Image $imageConfig -OsState Generalized -OsType Windows -
ManagedDiskId $diskID
5. Cree la imagen.
New-AzImage -ImageName $imageName -ResourceGroupName $rgName -Image $imageConfig
Creación de una imagen a partir de una instantánea mediante

PowerShell
Puede crear una imagen administrada a partir de una instantánea de una VM generalizada siguiendo estos pasos:
$snapshotName = "mySnapshot"
2. Obtenga la instantánea.
$snapshot = Get-AzSnapshot -ResourceGroupName $rgName -SnapshotName $snapshotName

$imageConfig = Set-AzImageOsDisk -Image $imageConfig -OsState Generalized -OsType Windows -SnapshotId
$snapshot.Id
4. Cree la imagen.
New-AzImage -ImageName $imageName -ResourceGroupName $rgName -Image $imageConfig
Creación de una imagen a partir de una máquina virtual que usa una
cuenta de almacenamiento
Para crear una imagen administrada a partir de una máquina virtual que no usa discos administrados, se necesita
el identificador URI del disco duro virtual del sistema operativo de la cuenta de almacenamiento en el siguiente
formato: https://mystorageaccount.blob.core.windows.net/vhdcontainer/vhdfilename.vhd. En este ejemplo, el
VHD está en mystorageaccount, en un contenedor denominado vhdcontainer, y el nombre de archivo de VHD es
vhdfilename.vhd.
$vmName = "myVM"
$osVhdUri = "https://mystorageaccount.blob.core.windows.net/vhdcontainer/vhdfilename.vhd"
2. Detenga/desasigne la máquina virtual.
3. Marque la VM como generalizada.
Set-AzVm -ResourceGroupName $rgName -Name $vmName -Generalized
4. Cree la imagen con el VHD del SO generalizado.

$imageConfig = Set-AzImageOsDisk -Image $imageConfig -OsType Windows -OsState Generalized -BlobUri
$osVhdUri
$image = New-AzImage -ImageName $imageName -ResourceGroupName $rgName -Image $imageConfig
Pasos siguientes
Creación de una máquina virtual a partir de una imagen administrada
Creación de una máquina virtual a partir de una
imagen administrada
Puede crear varias máquinas virtuales (VM ) a partir de una imagen de VM administrada con Azure mediante
PowerShell o Azure Portal. Una imagen de VM administrada contiene la información necesaria para crear una
VM, incluidos los discos del SO y de datos. Los discos duros virtuales (VHD ) que componen la imagen, incluidos
los discos del sistema operativo y los discos de datos, se almacenan como discos administrados.
Antes de crear una nueva máquina virtual, deberá crear una imagen de máquina virtual administrada para usarla
como la imagen de origen y conceder acceso de lectura en la imagen a cualquier usuario que deba tener acceso a
la imagen.
Uso del portal

2. En el menú izquierdo, seleccione Todos los recursos. Puede ordenar los recursos por Tipo para localizar
fácilmente sus imágenes.
3. Seleccione la imagen que desea usar en la lista. Se abre la página Información general de la imagen.
4. Seleccione Crear VM en el menú.
5. Escriba la información de la máquina virtual. El nombre de usuario y la contraseña que especifique aquí, se
usarán para iniciar sesión en la máquina virtual. Cuando haya terminado, seleccione Aceptar. Puede crear la
máquina virtual en un grupo de recursos existente, o bien hacer clic en Crear nuevo para crear un grupo de
recursos y así almacenar la máquina virtual.
6. Seleccione un tamaño para la máquina virtual. Para ver más tamaños, seleccione Ver todo o cambie el filtro
Supported disk type (Tipo de disco admitido).
7. En Configuración, realice cambios según sea necesario y haga clic en Aceptar.
8. En la página de resumen, verá el nombre de la imagen que se ha establecido como Imagen privada. Haga clic
en Aceptar para iniciar la implementación de la máquina virtual.
Uso de PowerShell
Puede usar PowerShell para crear una VM a partir de una imagen mediante el parámetro simplificado establecido
para el cmdlet New -AzVm. La imagen debe estar en el mismo grupo de recursos donde quiere crear la máquina
virtual.
El parámetro simplificado que se estableció para New -AzVm solo requiere que proporcione un nombre, un grupo
de recursos y un nombre de imagen para crear una VM a partir de una imagen. El cmdlet New -AzVm usará el
valor del parámetro -Name como nombre de todos los recursos que cree automáticamente. En este ejemplo, se
proporcionan nombres más detallados para cada uno de los recursos, pero se permite que el cmdlet los cree
automáticamente. También puede crear recursos de antemano, como la red virtual, y pasar el nombre del recurso
al cmdlet. New -AzVm usará los recursos existentes si los encuentra por su nombre.
En el ejemplo siguiente, se crea una máquina virtual denominada myVMfromImage en el grupo de recursos
myResourceGroup, a partir de la imagen llamada myImage.
New-AzVm `
-Name "myVMfromImage" `
-ImageName "myImage" `
-VirtualNetworkName "myImageVnet" `
-SubnetName "myImageSubnet" `
-SecurityGroupName "myImageNSG" `
-PublicIpAddressName "myImagePIP" `
-OpenPorts 3389
Pasos siguientes
Crear y administrar máquinas virtuales Windows con el módulo de Azure PowerShell
Uso de Packer para crear imágenes de máquinas
virtuales Windows en Azure
Cada máquina virtual (VM ) en Azure se crea a partir de una imagen que define la distribución de Windows y la
versión del sistema operativo. Las imágenes pueden incluir configuraciones y aplicaciones preinstaladas. Azure
Marketplace proporciona muchas imágenes propias y de terceros para los entornos de aplicaciones y sistemas
operativos más comunes, pero también puede crear sus propias imágenes personalizadas adaptadas a sus
necesidades. En este artículo se detalla cómo utilizar la herramienta de código abierto Packer para definir y crear
imágenes personalizadas en Azure.
Este artículo se probó por última vez el 21/02/2019 mediante la versión 1.3.0 del módulo Azure PowerShell y la
versión 1.3.4 de Packer.
NOTE
Azure tiene ahora un servicio, Azure Image Builder (versión preliminar), para definir y crear sus propias imágenes
personalizadas. Azure Image Builder se basa en Packer, por lo que puede usar incluso los scripts del aprovisionador de shell
de Packer. Para empezar a trabajar con Azure Image Builder, vea Vista previa: Crear una máquina virtual Windows con Azure
Image Builder.
Creación del grupo de recursos de Azure

Durante el proceso de compilación, Packer crea recursos de Azure temporales mientras genera la máquina virtual
de origen. Para capturar dicha máquina virtual para usarla como imagen, debe definir un grupo de recursos. La
salida del proceso de compilación de Packer se almacena en este grupo de recursos.
Cree un grupo de recursos con New -AzResourceGroup. En el ejemplo siguiente, se crea un grupo de recursos
denominado myResourceGroup en la ubicación eastus:
New-AzResourceGroup -Name $rgName -Location $location
Creación de credenciales de Azure

Packer se autentica con Azure mediante una entidad de servicio. Las entidades de servicio de Azure son
identidades de seguridad que pueden usarse con aplicaciones, servicios y herramientas de automatización como
Packer. El usuario controla los permisos y los define con respecto a cuáles son las operaciones que la entidad de
servicio puede realizar en Azure.
Cree una entidad de servicio con New -AzADServicePrincipal y asigne permisos para que la entidad de servicio
cree y administre recursos con New -AzRoleAssignment. El valor de -DisplayName debe ser único; reemplácelo por
su propio valor según sea necesario.
$sp = New-AzADServicePrincipal -DisplayName "PackerServicePrincipal"
$BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($sp.Secret)
$plainPassword = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)
New-AzRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $sp.ApplicationId
A continuación, genera el identificador de la aplicación y la contraseña.
$plainPassword
$sp.ApplicationId
Para autenticarse en Azure, también tendrá que obtener los identificadores de suscripción e inquilino de Azure con
Get-AzSubscription:
Get-AzSubscription
Definición de la plantilla de Packer

Para crear imágenes, es preciso crear una plantilla en forma de archivo JSON. En la plantilla, se definen los
generadores y aprovisionadores que realizan el proceso de creación real. Packer tiene un generador para Azure
que permite definir los recursos de Azure, como las credenciales de la entidad de servicio creadas en el paso
anterior.
Cree un archivo denominado windows.json y pegue el siguiente contenido. Escriba sus propios valores para los
siguientes elementos:
PARÁMETRO DÓNDE SE OBTIENE
client_id Vea el identificador de la entidad de servicio con

$sp.applicationId
client_secret Ver la contraseña generada automáticamente con

$plainPassword
tenant_id Salida del comando $sub.TenantId
subscription_id Salida del comando $sub.SubscriptionId
managed_image_resource_group_name Nombre del grupo de recursos que creó en el primer paso
managed_image_name Nombre de la imagen de disco administrado que se crea

{
"builders": [{
"type": "azure-arm",
"client_id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx",
"client_secret": "ppppppp-pppp-pppp-pppp-ppppppppppp",
"tenant_id": "zzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz",
"subscription_id": "yyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyy",
"managed_image_resource_group_name": "myResourceGroup",
"managed_image_name": "myPackerImage",
"os_type": "Windows",
"image_publisher": "MicrosoftWindowsServer",
"image_offer": "WindowsServer",
"image_sku": "2016-Datacenter",
"communicator": "winrm",
"winrm_use_ssl": true,
"winrm_insecure": true,
"winrm_timeout": "5m",
"winrm_username": "packer",
"azure_tags": {
"dept": "Engineering",
"task": "Image deployment"
},
"location": "East US",

"vm_size": "Standard_DS2_v2"
}],
"provisioners": [{
"type": "powershell",
"inline": [
"Add-WindowsFeature Web-Server",
"& $env:SystemRoot\\System32\\Sysprep\\Sysprep.exe /oobe /generalize /quiet /quit",
"while($true) { $imageState = Get-ItemProperty
HKLM:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Setup\\State | Select ImageState;
if($imageState.ImageState -ne 'IMAGE_STATE_GENERALIZE_RESEAL_TO_OOBE') { Write-Output $imageState.ImageState;
Start-Sleep -s 10 } else { break } }"
]
}]
}
Esta plantilla crea una máquina virtual de Windows Server 2016, instala IIS y generaliza la máquina virtual con
Sysprep. La instalación de IIS muestra cómo puede usar el aprovisionador de PowerShell para ejecutar comandos
adicionales. La imagen final de Packer incluye así la instalación y configuración del software necesario.
Creación de una imagen de Packer

Si Packer aún no está instalado en el equipo local, de compresor siga las instrucciones de instalación de Packer.
Para generar la imagen, abra el símbolo del sistema cmd y especifique el archivo de plantilla de Packer como
sigue:
./packer build windows.json
A continuación puede ver un ejemplo del resultado de los comandos anteriores:
azure-arm output will be in this color.
==> azure-arm: Running builder ...

azure-arm: Creating Azure Resource Manager (ARM) client ...
azure-arm: Creating Azure Resource Manager (ARM) client ...
==> azure-arm: Creating resource group ...
==> azure-arm: -> ResourceGroupName : ‘packer-Resource-Group-pq0mthtbtt’
==> azure-arm: -> Location : ‘East US’
==> azure-arm: -> Tags :
==> azure-arm: ->> task : Image deployment
==> azure-arm: ->> dept : Engineering
==> azure-arm: Validating deployment template ...
==> azure-arm: -> DeploymentName : ‘pkrdppq0mthtbtt’
==> azure-arm: Deploying deployment template ...
==> azure-arm: Getting the certificate’s URL ...
==> azure-arm: -> Key Vault Name : ‘pkrkvpq0mthtbtt’
==> azure-arm: -> Key Vault Secret Name : ‘packerKeyVaultSecret’
==> azure-arm: -> Certificate URL :
‘https://pkrkvpq0mthtbtt.vault.azure.net/secrets/packerKeyVaultSecret/8c7bd823e4fa44e1abb747636128adbb'
==> azure-arm: Setting the certificate’s URL ...
==> azure-arm: Validating deployment template ...
==> azure-arm: Deploying deployment template ...
==> azure-arm: Getting the VM’s IP address ...
==> azure-arm: -> PublicIPAddressName : ‘packerPublicIP’
==> azure-arm: -> NicName : ‘packerNic’
==> azure-arm: -> Network Connection : ‘PublicEndpoint’
==> azure-arm: -> IP Address : ‘40.76.55.35’
==> azure-arm: Waiting for WinRM to become available...
==> azure-arm: Connected to WinRM!
==> azure-arm: Provisioning with Powershell...
==> azure-arm: Provisioning with shell script: /var/folders/h1/ymh5bdx15wgdn5hvgj1wc0zh0000gn/T/packer-
powershell-provisioner902510110
azure-arm: #< CLIXML
azure-arm:
azure-arm: Success Restart Needed Exit Code Feature Result
azure-arm: ------- -------------- --------- --------------
azure-arm: True No Success {Common HTTP Features, Default Document, D...
azure-arm: <Objs Version=“1.1.0.1” xmlns=“http://schemas.microsoft.com/powershell/2004/04"><Obj
S=“progress” RefId=“0"><TN RefId=“0”><T>System.Management.Automation.PSCustomObject</T><T>System.Object</T>
</TN><MS><I64 N=“SourceId”>1</I64><PR N=“Record”><AV>Preparing modules for first use.</AV><AI>0</AI><Nil />
<PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj></Objs>
==> azure-arm: Querying the machine’s properties ...
==> azure-arm: -> ComputeName : ‘pkrvmpq0mthtbtt’
==> azure-arm: -> Managed OS Disk : ‘/subscriptions/guid/resourceGroups/packer-Resource-Group-
pq0mthtbtt/providers/Microsoft.Compute/disks/osdisk’
==> azure-arm: Powering off machine ...
==> azure-arm: -> ComputeName : ‘pkrvmpq0mthtbtt’
==> azure-arm: Capturing image ...
==> azure-arm: -> Compute ResourceGroupName : ‘packer-Resource-Group-pq0mthtbtt’
==> azure-arm: -> Compute Name : ‘pkrvmpq0mthtbtt’
==> azure-arm: -> Compute Location : ‘East US’
==> azure-arm: -> Image ResourceGroupName : ‘myResourceGroup’
==> azure-arm: -> Image Name : ‘myPackerImage’
==> azure-arm: -> Image Location : ‘eastus’
==> azure-arm: Deleting resource group ...
==> azure-arm: Deleting the temporary OS disk ...
==> azure-arm: -> OS Disk : skipping, managed disk was used...
Build ‘azure-arm’ finished.
==> Builds finished. The artifacts of successful builds are:

--> azure-arm: Azure.ResourceManagement.VMImage:
ManagedImageResourceGroupName: myResourceGroup
ManagedImageName: myPackerImage
ManagedImageLocation: eastus
Packer tarda unos minutos en crear la máquina virtual, ejecutar los aprovisionadores y limpiar la implementación.
Creación de una máquina virtual a partir de la imagen de Packer

Ya puede crear una VM a partir de la imagen con New -AzVM. Si aún no existen, se crean los recursos de red
complementarios. Cuando se le solicite, escriba un nombre de usuario administrativo y una contraseña que se
crearán en la máquina virtual. En el ejemplo siguiente se crea una máquina virtual denominada myVM a partir de
myPackerImage:
New-AzVm `
-Name "myVM" `
-OpenPorts 80 `
-Image "myPackerImage"
Si desea crear máquinas virtuales en un grupo de recursos o una región distintos a los de la imagen de Packer,
especifique el identificador de la imagen en lugar de su nombre. Puede obtener el identificador de imagen con
Get-AzImage.
La operación de creación de la máquina virtual a partir de la imagen de Packer tarda unos minutos.
Prueba de la máquina virtual y el servidor web

Obtenga la dirección IP pública de la VM con Get-AzPublicIPAddress. En el ejemplo siguiente se obtiene la
dirección IP de myPublicIP que se ha creado anteriormente:
-Name "myPublicIPAddress" | select "IpAddress"
Para ver en acción la máquina virtual, que incluye la instalación de IIS desde el aprovisionador de Packer, escriba
la dirección IP pública en un explorador web.
Pasos siguientes
También puede usar scripts existentes de aprovisionador de Packer con Azure Image Builder.
Uso del cliente Windows en Azure para escenarios de
desarrollo y pruebas
Puede usar Windows 7, Windows 8 o Windows 10 Enterprise (x64) en Azure para escenarios de desarrollo y
pruebas siempre que tenga una suscripción adecuada a Visual Studio (anteriormente MSDN ). En este artículo se
describen los requisitos de idoneidad para ejecutar Windows 7, Windows 8.1 o Windows 10 Enterprise en Azure y
usar las siguientes imágenes de la galería de Azure.
NOTE
Para la imagen de Windows 10 Pro y Windows 10 Pro N en la galería de Azure, consulte Implementación de Windows 10 en
Azure con derechos de hospedaje multiinquilino
Idoneidad de la suscripción
Los suscriptores activos de Visual Studio (es decir, las personas que adquirieron una licencia de suscripción de
Visual Studio) pueden usar el cliente Windows para desarrollo y pruebas. El cliente Windows se puede usar en su
propio hardware y en máquinas virtuales de Azure que se ejecutan en cualquier tipo de suscripción de Azure. El
cliente Windows no se puede implementar ni usar en Azure para un uso de producción normal. Tampoco lo
pueden usar quienes no son suscriptores activos de Visual Studio.
Para su comodidad, ciertas imágenes de Windows 10 están disponibles en la galería de Azure dentro de las
ofertas de desarrollo y pruebas a las que tiene acceso. Los suscriptores de Visual Studio dentro de cualquier tipo
de oferta también pueden preparar y crear apropiadamente una imagen de Windows 7, Windows 8 o Windows
10 de 64 bits y, luego, cargarla en Azure. El uso sigue limitado a desarrollo y pruebas por parte de los suscriptores
activos de Visual Studio.
Ofertas a las que se puede tener acceso

La tabla siguiente muestra los detalles de los id. de oferta idóneos para implementar Windows 10 a través de la
galería de Azure. Las imágenes de Windows 10 solo son visibles para las ofertas siguientes. Los suscriptores de
Visual Studio que deban ejecutar el cliente Windows en un tipo de oferta distinto necesitan que prepare y cree
apropiadamente una imagen de Windows 7, Windows 8 o Windows 10 de 64 bits y, luego, la cargue en Azure.
NOMBRE DE LA OFERTA NÚMERO DE LA OFERTA IMÁGENES DE CLIENTE DISPONIBLES
Desarrollo/pruebas - Pago por uso 0023P Windows 10
Suscriptores de Visual Studio Enterprise 0029P Windows 10

(MPN)
Suscriptores de Visual Studio 0059P Windows 10

Professional
Suscriptores de Visual Studio Test 0060P Windows 10

Professional
Visual Studio Premium con MSDN 0061P Windows 10

(ventaja)

(BizSpark)
Desarrollo/pruebas - Enterprise 0148P Windows 10
Compruebe la suscripción a Azure

Si no conoce el identificador de su oferta, puede obtenerlo en Azure Portal de una de estas dos formas:
En la ventana Suscripciones:
O bien, haga clic en Facturación y, a continuación, haga clic en el identificador de suscripción. El

identificador de oferta aparece en la ventana de facturación.
También puede ver el id. de la oferta en la pestaña "Suscripciones" del portal de la cuenta de Azure:
Pasos siguientes
Ahora puede implementar las máquinas virtuales con PowerShell, plantillas de Resource Manager o Visual Studio.
Descargar un VHD de Windows desde Azure
En este artículo aprenderá a descargar un archivo de disco duro virtual (VHD ) de Windows desde Azure mediante
Azure Portal.

No se puede descargar un VHD desde Azure si está conectado a una máquina virtual en ejecución. Debe detener la
máquina virtual para descargar un VHD. Si quiere usar un VHD como imagen para crear otras máquinas virtuales
con discos nuevos, use Sysprep para generalizar el sistema operativo incluido en el archivo y luego detenga la
máquina virtual. Para usar el VHD como disco para una nueva instancia de una máquina virtual o un disco de
datos existente, basta con detener y cancelar la asignación de la máquina virtual.
Para usar el VHD como imagen para crear otras máquinas virtuales, siga estos pasos:
1. Si aún no lo ha hecho, inicie sesión en el Azure Portal.
2. Conecte a la máquina virtual.
3. En la máquina virtual, abra la ventana del símbolo del sistema como administrador.
4. Cambie el directorio a %windir%\system32\sysprep y ejecute sysprep.exe.
5. En el cuadro de diálogo Herramienta de preparación del sistema, seleccione Iniciar la configuración rápida
(OOBE ) del sistema y asegúrese de que Generalizar está activado.
6. En Opciones de apagado, seleccione Apagar y luego haga clic en Aceptar.
Para usar el VHD como disco para una nueva instancia de una máquina virtual o un disco de datos existente,
realice estos pasos:
1. En el menú Concentrador de Azure Portal, haga clic en Máquinas virtuales.
3. En la hoja de la máquina virtual, haga clic en Detener.
Generación de dirección URL de SAS

Para descargar el archivo de VHD, debe generar una dirección URL de firma de acceso compartido (SAS ) . Una vez
generada la dirección URL, se asigna un tiempo de expiración a la dirección URL.
1. En el menú de la hoja de la máquina virtual, haga clic en Discos.
2. Seleccione el disco de sistema operativo de la máquina virtual y luego haga clic en Exportación del disco.
3. Establezca el tiempo de expiración de la dirección URL en 36000.
4. Haga clic en Generar dirección URL.
NOTE
El tiempo de expiración se aumenta con respecto al valor predeterminado para proporcionar tiempo suficiente para descargar
el archivo de VHD grande de un sistema operativo Windows Server. Es de esperar que un archivo de VHD que contenga el
sistema operativo Windows Server tarde varias horas en descargarse según la conexión. Si va a descargar un VHD de un disco
de datos, el tiempo predeterminado es suficiente.
Descargar VHD
1. En la dirección URL generada, haga clic en Descargar el archivo VHD.
2. Es posible que tenga que hacer clic en Guardar en el explorador para iniciar la descarga. El nombre
predeterminado del archivo de VHD es abcd.
Pasos siguientes
Más información sobre cómo cargar un archivo de VHD en Azure.
Create managed disks from unmanaged disks in a storage account (Creación de discos administrados a partir
de discos no administrados en una cuenta de almacenamiento).
Manage Azure disks with PowerShell (Administrar discos de Azure con PowerShell).
2 minutes to read
Administración de la disponibilidad de las máquinas
virtuales Windows en Azure
Aprenda a configurar y administrar varias máquinas virtuales para garantizar la alta disponibilidad de la
aplicación de Windows en Azure. También puede administrar la disponibilidad de las máquinas virtuales Linux.
Para obtener instrucciones sobre cómo crear y utilizar conjuntos de disponibilidad al usar el modelo de
implementación clásica, consulte Configuración de un conjunto de disponibilidad para máquinas virtuales en el
Información sobre los reinicios de máquinas virtuales: mantenimiento

frente a tiempo de inactividad
Hay tres escenarios que pueden afectar a la máquina virtual de Azure: mantenimiento de hardware no
planeado, tiempo de inactividad inesperado y mantenimiento planeado.
Un evento de mantenimiento de hardware no planeado se produce cuando la plataforma Azure
predice que en el hardware o en cualquier componente de plataforma asociado a una máquina física
está a punto de producirse un error. Cuando la plataforma predice un error, se emitirá un evento de
mantenimiento de hardware no planeado para reducir el efecto en las máquinas virtuales hospedadas
en ese hardware. Azure usa la tecnología Migración en vivo para migrar las máquinas virtuales del
hardware con errores a un equipo físico en buen estado. La migración en vivo es una operación de
conservación de máquinas virtuales que solo detiene la máquina virtual durante un breve período. Se
mantienen la memoria, los archivos abiertos y las conexiones de red pero el rendimiento puede verse
reducido antes o después del evento. En los casos en los que no se puede usar la migración en vivo, la
máquina virtual experimentará tiempos de inactividad inesperados, tal y como se describe a
continuación.
Un evento de tiempo de inactividad inesperado se produce cuando el hardware o la infraestructura
física de la máquina virtual produce un error de forma imprevista. Entre estos podemos encontrar
errores de la red local, errores de los discos locales u otras errores a nivel de bastidor. Cuando se detecta,
la plataforma Azure migra (recupera) automáticamente la máquina virtual a una máquina física en buen
estado en el mismo centro de datos. Durante el procedimiento de recuperación, las máquinas virtuales
experimentan tiempos de inactividad (reinicio) y, en algunos casos, pérdidas de la unidad temporal. El
sistema operativo y los discos de datos asociados siempre se conservan.
Las máquinas virtuales también pueden experimentar tiempos de inactividad en el improbable caso de
que una interrupción o desastre afecte a todo un centro de datos, o incluso a toda una región. Para estos
casos, Azure proporciona opciones de protección que incluyen zonas de disponibilidad y regiones
emparejadas.
Eventos de mantenimiento planeado son actualizaciones periódicas realizadas por Microsoft en la
plataforma Azure subyacente para mejorar en general la fiabilidad, el rendimiento y la seguridad de la
infraestructura de la plataforma sobre las que se funcionan sus máquinas virtuales. La mayoría de estas
actualizaciones se realizan sin que Virtual Machines ni Cloud Services resulten afectados (consulte
Mantenimiento de conservación de máquinas virtuales ). Aunque la plataforma Azure intente utilizar el
mantenimiento de conservación de máquinas virtuales en todas las ocasiones posibles, existen algunos
casos poco frecuentes en los que estas actualizaciones requieren un reinicio de la máquina virtual para
aplicar las actualizaciones necesarias a la infraestructura subyacente. En este caso, puede realizar un
mantenimiento planeado de Azure con la operación de reimplementación de mantenimiento mediante
el inicio del mantenimiento para sus máquinas virtuales en el período de tiempo adecuado. Para más
información, consulte Mantenimiento planeado de máquinas virtuales.
Para reducir el impacto del tiempo de parada debido a uno o más de estos eventos, recomendamos las
siguientes mejores prácticas de alta disponibilidad para las máquinas virtuales:
Configure varias máquinas virtuales en un conjunto de disponibilidad para la redundancia
Uso de Managed Disks para las máquinas virtuales de un conjunto de disponibilidad
Uso de eventos programados para responder de manera proactiva a eventos que afectan a la máquina
virtual
Configure cada nivel de aplicación en conjuntos separados de disponibilidad
Combinación de un equilibrador de carga con conjuntos de disponibilidad
Uso de zonas de disponibilidad para protegerse frente a errores en el nivel de centro de datos
Uso de zonas de disponibilidad para protegerse frente a errores en el

nivel de centro de datos
Las zonas de disponibilidad expanden el nivel de control que tiene para mantener la disponibilidad de las
aplicaciones y los datos en las máquinas virtuales. Las zonas de disponibilidad son ubicaciones físicas
exclusivas dentro de una región de Azure. Cada zona de disponibilidad consta de uno o varios centros de datos
equipados con alimentación, refrigeración y redes independientes. Para garantizar la resistencia, hay un mínimo
de tres zonas independientes en todas las regiones habilitadas. La separación física de las zonas de
disponibilidad dentro de una región protege las aplicaciones y los datos frente a los errores del centro de datos.
Los servicios con redundancia de zona replican las aplicaciones y los datos entre zonas de disponibilidad para
protegerlos frente a puntos de error únicos.
Una zona de disponibilidad de una región de Azure es una combinación de un dominio de error y un
dominio de actualización. Por ejemplo, si crea tres o más máquinas virtuales en tres zonas de una región de
Azure, las máquinas virtuales se distribuyen eficazmente en tres dominios de error y tres dominios de
actualización. La plataforma Azure reconoce esta distribución entre dominios de actualización para asegurarse
de que las máquinas virtuales de distintas zonas no se actualizan al mismo tiempo.
Con las zonas de disponibilidad, Azure ofrece el mejor Acuerdo de Nivel de Servicio del sector de tiempo de
actividad de máquina virtual, con un 99,99 %. Si diseña las soluciones para que usen máquinas virtuales
replicadas en zonas, puede proteger los datos y las aplicaciones frente a la pérdida de un centro de datos.
Aunque una zona esté en peligro, las aplicaciones y los datos replicados estarán disponibles instantáneamente
en otra zona.
Obtenga más información acerca de cómo implementar una máquina virtual Windows o Linux en una zona de
disponibilidad.
Configure varias máquinas virtuales en un conjunto de disponibilidad
para la redundancia
Los conjuntos de disponibilidad son otra configuración de centro de datos para proporcionar redundancia y
disponibilidad de máquina virtual. Esta configuración en un centro de datos garantiza que, durante un evento
de mantenimiento planeado o no planeado, hay al menos una máquina virtual disponible y cumple el 99,95 %
del Acuerdo de Nivel de Servicio de Azure. Para obtener más información, consulte Acuerdo de Nivel de
Servicio para máquinas virtuales.
IMPORTANT
Evite dejar una máquina virtual de instancia única sola en un conjunto de disponibilidad. En esta configuración, las
máquinas virtuales no reciben la garantía del Acuerdo de Nivel de Servicio y sufrirán un tiempo de inactividad durante los
eventos de mantenimiento planeado de Azure, excepto cuando solo una máquina virtual use discos SSD Premium de
Azure. El Acuerdo de Nivel de Servicio de Azure sí se aplica a las máquinas virtuales únicas que usen discos SSD Premium.
La plataforma Azure subyacente asigna a cada máquina virtual del conjunto de disponibilidad un dominio de
actualización y un dominio de error. Para un conjunto de disponibilidad dado, se asignan de forma
predeterminada cinco dominios de actualización que el usuario no puede configurar (las implementaciones de
Resource Manager pueden aumentarse para proporcionar un máximo de veinte dominios de actualización),
con el fin de indicar grupos de máquinas virtuales y el hardware físico subyacente que se pueden reiniciar
simultáneamente. Cuando se configuran más de cinco máquinas virtuales en un único conjunto de
disponibilidad, la sexta máquina virtual se coloca en el mismo dominio de actualización que la primera, la
séptima en el mismo que la segunda, y así sucesivamente. Es posible que el orden en que se reinician los
dominios de actualización no siga una secuencia durante un mantenimiento planeado, pero se reinician de uno
en uno. Un dominio de actualización reiniciado tiene 30 minutos para recuperar antes de que el mantenimiento
se inicie en un dominio de actualización diferente.
Los dominios de error definen un grupo de máquinas virtuales que comparten un origen de alimentación y un
interruptor de red comunes. De manera predeterminada, las máquinas virtuales configuradas en un conjunto
de disponibilidad se separan en hasta 3 dominios de error en las implementaciones con Resource Manager
(dos dominios de error en las implementaciones con el método clásico). Aunque colocar las máquinas virtuales
en un conjunto de disponibilidad no protege su aplicación contra errores del sistema operativo ni específicos de
aplicaciones, limita el impacto de posibles errores de hardware físico, interrupciones de red o cortes de
alimentación.
Uso de Managed Disks para las máquinas virtuales de un conjunto de
disponibilidad
Si actualmente está usando máquinas virtuales con discos no administrados, es muy recomendable convertir
las máquinas virtuales del conjunto de disponibilidad para que usen Managed Disks.
Managed Disks proporciona una mayor confiabilidad para los conjuntos de disponibilidad, ya que garantiza
que los discos de las máquinas virtuales de un conjunto de disponibilidad estén suficientemente aislados entre
sí para evitar puntos únicos de error. Para ello, coloca automáticamente los discos en dominios de error de
almacenamiento diferentes (clústeres de almacenamiento) y los alinea con el dominio de error de la máquina
virtual. Si se produce un error en un dominio de error de almacenamiento debido a un error de hardware o
software, solo presentará errores la instancia de máquina virtual que tenga discos en el dominio de error de
almacenamiento.
IMPORTANT
El número de dominios de error para conjuntos de disponibilidad administrados varía según la región, entre dos y tres
por región. En la tabla siguiente se muestra el número por región.
Número de dominios de error por región

REGION NÚMERO MÁXIMO DE DOMINIOS DE ERROR
East US 3
Este de EE. UU. 2 3
Oeste de EE. UU. 3
Oeste de EE. UU. 2 2
Centro de EE. UU. 3
Centro-Norte de EE. UU 3
Centro-Sur de EE. UU 3
Centro occidental de EE.UU. 2
Centro de Canadá 3
Este de Canadá 2
Europa del Norte 3
Europa occidental 3
Sur de Reino Unido 2 2
Oeste de Reino Unido 2
Asia oriental 2
Sudeste de Asia 2
Este de Japón 2
Oeste de Japón 2
Sur de la India 2
India Central 2
Oeste de la India 2
REGION NÚMERO MÁXIMO DE DOMINIOS DE ERROR
Corea Central 2
Corea del Sur 2
Norte de Emiratos Árabes Unidos 2
Este de China 2
Este de China 2 2
Norte de China 2
Norte de China 2 2
Este de Australia 2
Sudeste de Australia 2
Centro de Australia 2
Centro de Australia 2 2
Sur de Brasil 2
Gobierno de EE. UU. - Virginia 2
Gobierno de EE. UU.: Texas 2
Gobierno de EE. UU.: Arizona 2
Departamento de Defensa de EE. UU. Centro 2
Departamento de Defensa de EE. UU. Este 2
Nota: En determinadas circunstancias, podría ocurrir que dos máquinas virtuales del mismo AvailabilitySet
compartan el mismo FaultDomain. Para confirmarlo, vaya a su AvailabilitySet y compruebe la columna
"Dominio de error". Este comportamiento se puede observar cuando se produjo la siguiente secuencia al
implementar las máquinas virtuales:
Implementar la primera máquina virtual
Detener o desasignar la primera máquina virtual
Implementar la segunda máquina virtual en estas circunstancias, el disco del sistema operativo de la
segunda máquina virtual puede crearse en el mismo dominio de error que la primera máquina virtual,
por lo que la segunda máquina virtual también aterrizará en el mismo FaultDomain. Para evitar este
problema, se recomienda no detener ni desasignar la máquina virtual entre sus implementaciones.
Si tiene previsto usar máquinas virtuales con discos no administrados, siga los procedimientos recomendados
que aparecen a continuación para las cuentas de almacenamiento donde se almacenan los discos duros
virtuales (VHD ) de las máquinas virtuales como blobs en páginas.
1. Mantenga todos los discos (sistema operativo y datos) asociados a una máquina virtual en la
misma cuenta de almacenamiento.
2. Revise los límites en el número de discos no administrados de una cuenta de almacenamiento
antes de agregar más discos duros virtuales a esta
3. Utilice una cuenta de almacenamiento independiente para cada máquina virtual de un conjunto
de disponibilidad. No comparta las cuentas de almacenamiento con varias máquinas virtuales del mismo
conjunto de disponibilidad. Las máquinas virtuales de distintos conjuntos de disponibilidad pueden
compartir las cuentas de almacenamiento si se siguen los procedimientos recomendados anteriores.
Uso de eventos programados para responder de manera proactiva a

eventos que afectan a la máquina virtual
Cuando se suscribe a eventos programados, se le notifica a la máquina virtual sobre próximos eventos de
mantenimiento que pueden afectar a su funcionamiento. Si los eventos programados están habilitados, se le da
a la máquina virtual una cantidad mínima de tiempo antes de que se lleve a cabo la actividad de
mantenimiento. Por ejemplo, las actualizaciones del sistema operativo del host que pueden afectar a la
máquina virtual se ponen en cola como eventos en los que se especifica el impacto, así como la hora en que se
efectuará el mantenimiento si no se realiza ninguna acción. Los eventos de programación también se ponen en
cola cuando Azure detecta un error inminente del hardware que podría afectar a la máquina virtual, lo cual
permite al usuario decidir cuándo se debe realizar la recuperación. Los clientes pueden usar el evento para
realizar determinadas tareas antes del mantenimiento, como guardar el estado, conmutar por error a la base de
datos secundaria, etc. Después de completar la lógica para controlar correctamente el evento de
mantenimiento, puede aprobar el evento programado pendiente para permitir que la plataforma continúe con
el mantenimiento.
Configure cada capa de aplicación en zonas de disponibilidad o

conjuntos de disponibilidad independientes
Si las máquinas virtuales son todas prácticamente idénticas y tienen la misma función en la aplicación, se
recomienda configurar una zona de disponibilidad o un conjunto de disponibilidad para cada capa de la
aplicación. Si coloca dos capas diferentes en la misma zona o conjunto de disponibilidad, todas las máquinas
virtuales de la misma capa de aplicación se pueden reiniciar a la vez. Al configurar al menos dos máquinas
virtuales en una zona o un conjunto de disponibilidad para cada capa, se garantiza que al menos haya
disponible una en cada capa.
Por ejemplo, podría colocar todas las máquinas virtuales del front-end de la aplicación que ejecuta IIS, Apache
y Nginx en un solo conjunto o zona de disponibilidad. Asegúrese de que solo las máquinas virtuales del front-
end se colocan en el mismo conjunto o zona de disponibilidad. De la misma manera, asegúrese de que solo las
máquinas virtuales de la capa de datos se colocan en su propio conjunto o zona de disponibilidad, por ejemplo,
las máquinas virtuales replicadas de SQL Server o las de MySQL.
Combinación de un equilibrador de carga con conjuntos o zonas de

disponibilidad
Combine Azure Load Balancer con un conjunto o zona de disponibilidad para aprovechar al máximo la
resistencia de la aplicación. El equilibrador de carga de Azure distribuye el tráfico entre varias máquinas
virtuales. El equilibrador de carga de Azure está incluido en nuestras máquinas virtuales de niveles estándar.
No todos los niveles de las máquinas virtuales incluyen Azure Load Balancer. Para obtener más información
sobre el equilibrio de carga en máquinas virtuales, consulte Equilibrio de carga de máquinas virtuales.
Si el equilibrador de carga no está configurado para equilibrar el tráfico entre varias máquinas virtuales,
cualquier evento de mantenimiento planeado afectará a la única máquina virtual dedicada al tráfico, lo que
provocará una interrupción en el nivel de la aplicación. Si se colocan varias máquinas virtuales del mismo nivel
en el mismo equilibrador de carga y conjunto de disponibilidad, se permitirá tener un tráfico continuamente
disponible asistido por, al menos, una instancia.
Para obtener un tutorial sobre cómo equilibrar la carga entre las zonas de disponibilidad, vea Equilibrio de
carga de máquinas virtuales en todas las zonas de disponibilidad con la CLI de Azure.
Pasos siguientes
Para más información sobre el equilibrio de carga de las máquinas virtuales, consulte Equilibrio de carga para
servicios de infraestructura de Azure.
Cree un grupo de selección de ubicación de
proximidad con el portal
Para acercar las máquinas virtuales lo máximo posible con la menor latencia, debe implementarlas dentro de un
grupo de selección de ubicación de proximidad.
Un grupo de selección de ubicación de proximidad es una agrupación lógica que se usa para asegurarse de que los
recursos de proceso de Azure se encuentran físicamente cercanos entre sí. Los grupos de selección de ubicación de
proximidad son útiles para las cargas de trabajo en las que la latencia baja es un requisito.
Creación de un grupo de selección de ubicación de proximidad

1. Escriba proximity placement group 'grupo de selección de ubicación de proximidad' en el cuadro de
búsqueda.
2. En Servicios en los resultados de la búsqueda, seleccione Proximity placement groups (Grupos de
selección de ubicación de proximidad) .
3. En la página Grupos de selección de ubicación de proximidad, seleccione Agregar.
4. En la pestaña Datos básicos, en Detalles del proyecto, asegúrese de que está seleccionada la suscripción
correcta.
5. En Grupo de recursos seleccione Crear nuevo para crear un nuevo grupo o seleccione un grupo de
recursos existente de la lista desplegable.
6. En Región seleccione la ubicación en la que desea crear el grupo de selección de ubicación de proximidad.
7. En Nombre de grupo de ubicación de proximidad escriba un nombre y luego seleccione Revisar +
crear.
8. Una vez que se haya superado la validación, seleccione Crear para crear el grupo de selección de ubicación
de proximidad.
Crear una VM
1. Al crear una máquina virtual en el portal, vaya a la pestaña Advanced.
2. En la selección Grupo de selección de ubicación de proximidad, elija el grupo de ubicación correcto.
3. Cuando haya terminado de realizar todas las demás selecciones necesarias, seleccione Revisar + crear.
4. Después de pasar la validación, seleccione Crear para implementar la máquina virtual en el grupo de
ubicación.
Pasos siguientes
También puede usar Azure PowerShell para crear grupos de selección de ubicación de proximidad.
Implementación de máquinas virtuales en grupos de
selección de ubicación de proximidad con PowerShell
Para acercar las máquinas virtuales lo máximo posible con la menor latencia, debe implementarlas dentro de un
Un grupo de selección de ubicación de proximidad es una agrupación lógica que se usa para asegurarse de que
los recursos de proceso de Azure se encuentran físicamente cercanos entre sí. Los grupos de selección de
ubicación de proximidad son útiles para las cargas de trabajo en las que la latencia baja es un requisito.
Creación de un grupo de selección de ubicación por proximidad

Cree un grupo de selección de ubicación de proximidad con el cmdlet New -AzProximityPlacementGroup.
$resourceGroup = "myPPGResourceGroup"
$ppgName = "myPPG"
$ppg = New-AzProximityPlacementGroup `
-Name $ppgName `
-ProximityPlacementGroupType Standard
Enumeración de los grupos de selección de ubicación de proximidad

Puede enumerar todos los grupos de selección de ubicación de proximidad mediante el cmdlet Get-
AzProximityPlacementGroup.
Get-AzProximityPlacementGroup
Crear una VM
Cree una máquina virtual en el grupo de selección de ubicación de proximidad con
-ProximityPlacementGroup $ppg.Id para hacer referencia al identificador de grupo de selección de ubicación de
proximidad cuando use New -AzVM para crear la máquina virtual.
$vmName = "myVM"
New-AzVm `
-Name $vmName `
-OpenPorts 3389 `
-ProximityPlacementGroup $ppg.Id
Puede ver la máquina virtual en el grupo de selección de ubicación mediante Get-AzProximityPlacementGroup.

Get-AzProximityPlacementGroup -ResourceId $ppg.Id |
Format-Table -Property VirtualMachines -Wrap
También puede crear un conjunto de disponibilidad en el grupo de selección de ubicación de proximidad. Use el
mismo parámetro -ProximityPlacementGroup con el cmdlet New -AzAvailabilitySet para crear un conjunto de
disponibilidad, y todas las máquinas virtuales del conjunto de disponibilidad también se crearán en el mismo
Conjuntos de escalado
También puede crear un conjunto de escalado en el grupo de selección de ubicación de proximidad. Use el mismo
parámetro -ProximityPlacementGroup con New -AzVmss para crear un conjunto de escalado, y todas las instancias
se crearán en el mismo grupo de selección de ubicación de proximidad.
Pasos siguientes
También puede usar la CLI de Azure para crear grupos de selección de ubicación de proximidad.
Creación de una máquina virtual Windows en una
zona de disponibilidad con PowerShell
En este artículo se detallan el uso de Azure PowerShell para crear una máquina virtual de Azure que ejecute
Windows Server 2016 en una zona de disponibilidad de Azure. Una zona de disponibilidad es una zona separada
físicamente en una región de Azure. Use zonas de disponibilidad para proteger sus datos y aplicaciones de la
improbable pérdida o error de todo un centro de datos.
Para usar una zona de disponibilidad, cree la máquina virtual en una región de Azure compatible.

Inicie sesión en la suscripción a Azure con el comando Connect-AzAccount y siga las instrucciones de la pantalla.
Connect-AzAccount
Comprobación de la disponibilidad del SKU de la máquina virtual

La disponibilidad de tamaños de máquinas virtuales o SKU puede variar según la región y la zona. Para ayudarle
a planear el uso de las Zonas de disponibilidad, puede enumerar las SKU de la máquina virtual disponibles por
región de Azure y zona. Con esta funcionalidad se asegura de elegir un tamaño apropiado de máquina virtual y
obtener la resistencia deseada en las distintas zonas. Para más información sobre los diferentes tipos y tamaños
de máquina virtual, consulte Introducción a los tamaños de máquina virtual.
Puede ver las SKU de máquina virtual disponibles con el comando Get-AzComputeResourceSku. En el ejemplo
siguiente se enumeran las SKU de máquina virtual disponibles en la región eastus2:
Get-AzComputeResourceSku | where {$_.Locations.Contains("eastus2")};
La salida es similar al siguiente ejemplo reducido, en el que se muestran las Zonas de disponibilidad en las que
está disponible cada tamaño de máquina virtual:
ResourceType Name Location Zones [...]

------------ ---- -------- -----
virtualMachines Standard_DS1_v2 eastus2 {1, 2, 3}
virtualMachines Standard_DS2_v2 eastus2 {1, 2, 3}
[...]
virtualMachines Standard_F1s eastus2 {1, 2, 3}
virtualMachines Standard_F2s eastus2 {1, 2, 3}
[...]
virtualMachines Standard_D2s_v3 eastus2 {1, 2, 3}
virtualMachines Standard_D4s_v3 eastus2 {1, 2, 3}
[...]
virtualMachines Standard_E2_v3 eastus2 {1, 2, 3}
virtualMachines Standard_E4_v3 eastus2 {1, 2, 3}

en el que se implementan y se administran los recursos de Azure. En este ejemplo se crea un grupo de recursos
denominado myResourceGroup en la región eastus2.
New-AzResourceGroup -Name myResourceGroup -Location EastUS2
Creación de los recursos de red principales

Cree una red virtual, una subred y una dirección IP pública
Estos recursos se utilizan para proporcionar conectividad de red a la máquina virtual y conectarse a Internet. Cree
la dirección IP en una zona de disponibilidad, en este ejemplo, 2. En un paso posterior, puede crear la máquina
virtual en la misma zona que se usó para crear la dirección IP.
# Create a subnet configuration

# Create a virtual network

$vnet = New-AzVirtualNetwork -ResourceGroupName myResourceGroup -Location eastus2 `
-Name myVNet -AddressPrefix 192.168.0.0/16 -Subnet $subnetConfig
# Create a public IP address in an availability zone and specify a DNS name

$pip = New-AzPublicIpAddress -ResourceGroupName myResourceGroup -Location eastus2 -Zone 2 `
-AllocationMethod Static -IdleTimeoutInMinutes 4 -Name "mypublicdns$(Get-Random)"
Creación de un grupo de seguridad de red y una regla de grupo de seguridad de red

El grupo de seguridad de red protege la máquina virtual con reglas entrantes y salientes. En este caso, se crea una
regla de entrada para el puerto 3389, que permite las conexiones entrantes al Escritorio remoto. También
queremos crear una regla de entrada para el puerto 80, que permita el tráfico web entrante.


$nsgRuleWeb = New-AzNetworkSecurityRuleConfig -Name myNetworkSecurityGroupRuleWWW -Protocol Tcp `

$nsg = New-AzNetworkSecurityGroup -ResourceGroupName myResourceGroup -Location eastus2 `
-Name myNetworkSecurityGroup -SecurityRules $nsgRuleRDP,$nsgRuleWeb
Creación de una tarjeta de red para la máquina virtual

Cree una tarjeta de red con New -AzNetworkInterface para la máquina virtual. Esta conecta la máquina virtual a
una subred, un grupo de seguridad de red y una dirección IP pública.
# Create a virtual network card and associate with public IP address and NSG
$nic = New-AzNetworkInterface -Name myNic -ResourceGroupName myResourceGroup -Location eastus2 `

Cree una configuración de máquina virtual. Esta configuración incluye los ajustes que se usan al implementar la
máquina virtual como una imagen de máquina virtual, el tamaño y la configuración de autenticación. El tamaño
Standard_DS1_v2 de este ejemplo se admite en las zonas de disponibilidad. Esta configuración también especifica
la zona de disponibilidad que se establece al crear la dirección IP. Cuando se realiza este paso, se le solicitará las
credenciales. Los valores que especifique se configuran como el nombre de usuario y la contraseña de la máquina
virtual.
# Define a credential object


$vmConfig = New-AzVMConfig -VMName myVM -VMSize Standard_DS1_v2 -Zone 2 | `
Set-AzVMOperatingSystem -Windows -ComputerName myVM -Credential $cred | `
-Skus 2016-Datacenter -Version latest | Add-AzVMNetworkInterface -Id $nic.Id
Cree la máquina virtual con New -AzVM.
New-AzVM -ResourceGroupName myResourceGroup -Location eastus2 -VM $vmConfig
Confirmación de zona para disco administrado

Ha creado el recurso de dirección IP de la máquina virtual en la misma zona de disponibilidad que la máquina
virtual. También se crea el recurso de disco administrado para la máquina virtual en la misma zona de
disponibilidad. Puede comprobarlo con Get-AzDisk:
Get-AzDisk -ResourceGroupName myResourceGroup
La salida muestra que el disco administrado está en la misma zona de disponibilidad que la máquina virtual:
ResourceGroupName : myResourceGroup
AccountType : PremiumLRS
OwnerId : /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/myResourceGroup/providers/Microsoft.
Compute/virtualMachines/myVM
ManagedBy : /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx//resourceGroups/myResourceGroup/providers/Microsoft.
Compute/virtualMachines/myVM
Sku : Microsoft.Azure.Management.Compute.Models.DiskSku
Zones : {2}
TimeCreated : 9/7/2017 6:57:26 PM
OsType : Windows
CreationData : Microsoft.Azure.Management.Compute.Models.CreationData
DiskSizeGB : 127
EncryptionSettings :
ProvisioningState : Succeeded
Id : /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/myResourceGroup/providers/Microsoft.
Compute/disks/myVM_OsDisk_1_bd921920bb0a4650becfc2d830000000
Name : myVM_OsDisk_1_bd921920bb0a4650becfc2d830000000
Type : Microsoft.Compute/disks
Location : eastus2
Tags : {}
Pasos siguientes
En este artículo, ha aprendido a crear una máquina virtual en una zona de disponibilidad. Aprenda más sobre la
disponibilidad de las máquinas virtuales de Azure.
Creación de una máquina virtual Windows en una
zona de disponibilidad con Azure Portal
En este artículo se describe el uso de Azure Portal para crear una máquina virtual en una zona de disponibilidad de
Azure. Una zona de disponibilidad es una zona separada físicamente en una región de Azure. Use zonas de
disponibilidad para proteger sus datos y aplicaciones de la improbable pérdida o error de todo un centro de datos.
Para usar una zona de disponibilidad, cree la máquina virtual en una región de Azure compatible.


1. Haga clic en Crear un recurso en la esquina superior izquierda de Azure Portal.
2. Seleccione Compute y, después, seleccione Windows Server 2016 Datacenter.
3. Escriba la información de la máquina virtual. El nombre de usuario y la contraseña que especifique aquí se
usarán para iniciar sesión en la máquina virtual. La contraseña debe tener al menos 12 caracteres de largo y
cumplir con los requisitos de complejidad definidos. Elija una ubicación como Este de EE. UU. 2 que admita
las zonas de disponibilidad. Cuando haya terminado, haga clic en Aceptar.
4. Elija un tamaño para la máquina virtual. Seleccione un tamaño recomendado o filtre en función de las
características. Confirme que el tamaño esté disponible en la zona que desea usar.
5. En Configuración > Alta disponibilidad, seleccione una de las zonas numeradas en la lista desplegable
Zona de disponibilidad, mantenga el resto de valores predeterminados y haga clic en Aceptar.
6. En la página de resumen, haga clic en Crear para iniciar la implementación de la máquina virtual.
7. La máquina virtual se anclará al panel de Azure Portal. Una vez completada la implementación, se abrirá
automáticamente el resumen de la máquina virtual.
Confirmación de zona para disco administrado y dirección IP

Cuando la máquina virtual se implementa en una zona de disponibilidad, se crea un disco administrado para la
máquina virtual en la misma zona de disponibilidad. De forma predeterminada, también se crea una dirección IP
pública en dicha zona.
Puede confirmar la configuración de zona para estos recursos en el portal.
1. Haga clic en Grupos de recursos y en el nombre del grupo de recursos para la máquina virtual, como
myResourceGroup.
2. Haga clic en el nombre del recurso de disco. La página Información general incluye detalles sobre la
ubicación y la zona de disponibilidad del recurso.
3. Haga clic en el nombre del recurso de la dirección IP pública. La página Información general incluye
detalles sobre la ubicación y la zona de disponibilidad del recurso.
Pasos siguientes
En este artículo, ha aprendido a crear una máquina virtual en una zona de disponibilidad. Aprenda más sobre la
disponibilidad de las máquinas virtuales de Azure.
Automatización de la implementación de la máquina
virtual de Azure con Chef
Chef es una fantástica herramienta para ofrecer automatización y las configuraciones de estado que desee.
Con la versión de API de nube más reciente, Chef proporciona una perfecta integración con Azure, lo que ofrece la
posibilidad de aprovisionar e implementar los estados de configuración mediante un único comando.
En este artículo, se configura un entorno de Chef para aprovisionar máquinas virtuales de Azure y se le guía por la
creación de una directiva o "libro de recetas", y su posterior implementación en una máquina virtual de Azure.
Conceptos básicos de Chef

Antes de comenzar, revise los conceptos básicos de Chef.
El diagrama siguiente muestra la arquitectura Chef de alto nivel.
La arquitectura de Chef tiene tres componentes principales: el servidor Chef, el cliente Chef (nodo) y la estación de
trabajo Chef.
El servidor Chef es el punto de administración y hay dos opciones para el servidor Chef: una solución hospedada
o una solución local.
El cliente Chef (nodo) es el agente que se encuentra en los servidores que está administrando.
La estación de trabajo Chef es el nombre tanto de la estación de trabajo de administración en la que se crean
directivas y se ejecutan comandos de administración como del paquete de software de las herramientas de Chef.
Por lo general, verá su estación de trabajo como la ubicación en la que puede realizar acciones y la estación de
trabajo Chef como el paquete de software. Por ejemplo, el comando de knife se descargará como parte de la
estación de trabajo Chef, pero los comandos de knife que administran la infraestructura se ejecutan desde su
estación de trabajo.
Chef también usa los conceptos de "libros de recetas" y "recetas", que son realmente las directivas que definimos y
aplicamos a los servidores.
Preparación de la estación de trabajo

En primer lugar, prepare la estación de trabajo mediante la creación de un directorio que almacene archivos de
configuración de Chef y libros de recetas.
Cree un directorio denominado C:\Chef.
Descargue e instale la última versión de la CLI de Azure en su estación de trabajo.
Configuración de una entidad de servicio de Azure

Explicándolo de forma sencilla, una entidad de servicio de Azure es una cuenta de servicio. Usaremos una entidad
de servicio para ayudarnos a crear recursos de Azure desde nuestra estación de trabajo Chef. Para crear la entidad
de servicio correspondiente con los permisos necesarios, tenemos que ejecutar los siguientes comandos en
PowerShell:
Login-AzureRmAccount
Get-AzureRmSubscription
Select-AzureRmSubscription -SubscriptionName "<yourSubscriptionName>"
$myApplication = New-AzureRmADApplication -DisplayName "automation-app" -HomePage "https://chef-automation-
test.com" -IdentifierUris "https://chef-automation-test.com" -Password "#1234p$wdchef19"
New-AzureRmADServicePrincipal -ApplicationId $myApplication.ApplicationId
New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $myApplication.ApplicationId
Apunte los valores de SubscriptionID, TenantID, ClientID y el secreto de cliente (la contraseña que ha establecido
antes), los necesitará más adelante.
Configuración del servidor Chef

En esta guía se da por supuesto que se registrará para Hosted Chef.
Si no usa un servidor Chef, puede:
Registrarse para obtener Hosted Chef, que es la forma más rápida de empezar a usar Chef.
Instalar un servidor Chef independiente en el equipo con Linux siguiendo las instrucciones de instalación de
Chef Docs.
Creación de una cuenta de Hosted Chef
Para disfrutar de una cuenta de Hosted Chef, regístrese aquí.
Durante el proceso de registro, se le pedirá que cree una organización.
Cuando se cree la organización, descargue el starter kit.
NOTE
Si recibe un mensaje que le advierte que se restablecerán las claves, está bien continuar como si no tuviéramos ninguna
infraestructura existente configurada todavía.
El archivo zip de Starter Kit contiene los archivos de configuración y la clave de usuario de la organización que
están en el directorio .chef .
organization-validator.pem debe descargarse por separado, porque es una clave privada y las claves privadas no
se deben almacenar en el servidor Chef. En Chef Manage, vaya a la sección de administración y seleccione "Reset
Validation Key" (Restablecer clave de validación); se le proporcionará un archivo que se descarga por separado.
Guarde el archivo en c:\chef.
Configuración de la estación de trabajo Chef
Extraiga el contenido del archivo chef-starter.zip en c:\chef.
Copie todos los archivos de chef-starter\chef-repo.chef en el directorio c:\chef.
Copie el archivo organization-validator.pem en c:\chef, si se guarda en c:\Downloads
El directorio debería tener ahora un aspecto similar al siguiente ejemplo.
Directory: C:\Users\username\chef
Mode LastWriteTime Length Name

---- ------------- ------ ----
d----- 12/6/2018 6:41 PM .chef
d----- 12/6/2018 5:40 PM chef-repo
d----- 12/6/2018 5:38 PM cookbooks
d----- 12/6/2018 5:38 PM roles
-a---- 12/6/2018 5:38 PM 495 .gitignore
-a---- 12/6/2018 5:37 PM 1678 azuredocs-validator.pem
-a---- 12/6/2018 5:38 PM 1674 user.pem
-a---- 12/6/2018 5:53 PM 414 knife.rb
-a---- 12/6/2018 5:38 PM 2341 README.md
Ahora debería tener cinco archivos y cuatro directorios (incluido el directorio chef-repo vacío) en la raíz de c:\chef.
Edición de knife.rb
Los archivos PEM contienen sus claves privadas de organización y administración para la comunicación y el
archivo knife.rb contiene la configuración de knife. Tendremos que editar el archivo knife.rb.
Abra el archivo knife.rb en el editor que prefiera. El archivo sin modificar debe ser similar a este:
log_level :info
log_location STDOUT
node_name "mynode"
client_key "#{current_dir}/user.pem"
cookbook_path ["#{current_dir}/cookbooks"]
Agregue la siguiente información a knife.rb:

validation_client_name "validador-de-la-organización"
validation_key "#{directorio_actual}/myorg.pem"
Estas líneas asegurarán que Knife haga referencia al directorio de cookbooks en c:\chef\cookbooks y que también
use la entidad de servicio de Azure que ha creado durante las operaciones de Azure.
Ahora el archivo knife.rb debería ser ahora similar al del siguiente ejemplo:
log_level :info
log_location STDOUT
node_name "myorg"
client_key "#{current_dir}/myorg.pem"
validation_client_name "myorg-validator"
validation_key "#{current_dir}/myorg-validator.pem"
cookbook_path ["#{current_dir}/../cookbooks"]
Instalación de la estación de trabajo Chef

A continuación, descargue e instale la estación de trabajo Chef. Instale la estación de trabajo Chef en la ubicación
predeterminada. Esta instalación puede tardar unos minutos.
En el escritorio, verá "CW PowerShell", que es un entorno que se carga con la herramienta que se necesita para
interactuar con los productos de Chef. CW PowerShell permite usar nuevos comandos ad hoc, como chef-run ,
así como comandos tradicionales de la CLI de Chef, como chef . Consulte la versión instalada de la estación de
trabajo Chef y de las herramientas de Chef con chef -v . También puede consultar la versión de la estación de
trabajo. Para ello, debe seleccionar "About Chef Workstation" (Acerca de la estación de trabajo Chef) en la
aplicación de la estación de trabajo Chef.
chef --version debe devolver algo similar a esto:
Chef Workstation: 0.4.2

chef-run: 0.3.0
chef-client: 15.0.300
delivery-cli: 0.0.52 (9d07501a3b347cc687c902319d23dc32dd5fa621)
berks: 7.0.8
test-kitchen: 2.2.5
inspec: 4.3.2
NOTE
El orden de la ruta de acceso es importante. Si las rutas de acceso de opscode no están en el orden correcto, tendrá
problemas.
Reinicie la estación de trabajo antes de continuar.

Instalación de Knife Azure
En este tutorial se da por supuesto que usa Azure Resource Manager para interactuar con su máquina virtual.
Instale la extensión de Knife Azure. De esta se proporciona a Knife el "complemento de Azure".
Ejecute el siguiente comando.
chef gem install knife-azure ––pre
NOTE
El argumento –pre garantiza que está recibiendo la versión de RC más reciente del complemento Knife Azure que ofrece
acceso al conjunto más reciente de API.
Es probable que también se instalen varias dependencias al mismo tiempo.
Para garantizar que todo esté configurado correctamente, ejecute el siguiente comando.
knife azurerm server list
Si todo está configurado correctamente, verá una lista de imágenes de Azure disponibles en desplazamiento.
¡ Enhorabuena! La estación de trabajo está configurada.
Crear una guía

Chef usa las guías para definir un conjunto de comandos que desea ejecutar en el cliente administrado. La
creación de un libro de recetas es un proceso sencillo, solo haya que usar el comando chef generate cookbook
para generar la plantilla del libro de recetas. Dicho libro de recetas es para un servidor web que implementa IIS
automáticamente.
En el directorio C:\Chef, ejecute el siguiente comando.
chef generate cookbook webserver
Este comando genera un conjunto de archivos en el directorio C:\Chef\cookbooks\webserver. A continuación,

defina el conjunto de comandos que el cliente Chef ejecutara en la máquina virtual administrada.
Los comandos se almacenan en el archivo default.rb. En dicho archivo, defina un conjunto de comandos que
instala IIS, inicia IIS y copia un archivo de plantilla en la carpeta wwwroot.
Modifique el archivo C:\chef\cookbooks\webserver\recipes\default.rb y agregue las siguientes líneas.
powershell_script 'Install IIS' do
action :run
code 'add-windowsfeature Web-Server'
end
service 'w3svc' do
action [ :enable, :start ]
end
template 'c:\inetpub\wwwroot\Default.htm' do
source 'Default.htm.erb'
rights :read, 'Everyone'
end
Cuando haya terminado, guarde el archivo.
Crear una plantilla

En este paso, generará un archivo de plantilla que se va a utilizar como la página default.html.
Ejecute el siguiente comando para generar la plantilla:
chef generate template webserver Default.htm
Vaya al archivo C:\chef\cookbooks\webserver\templates\default\Default.htm.erb . Edite el archivo agregando el

código HTML simple "Hello World" y guarde el archivo.
Cargar la guía en el servidor Chef

En este paso se realiza una copia de la guía que se ha creado en el equipo local y se cargamos en el servidor
hospedado de Chef. Una vez que se carga, la guía aparece en la pestaña Policy (Directiva).
knife cookbook upload webserver
Implementar una máquina virtual con Knife Azure

Implemente una máquina virtual de Azure y aplique la guía "Webserver", que instalará el servicio web de IIS y la
página web predeterminada.
Para ello, use el comando knife azurerm server create.
A continuación aparece un ejemplo del comando.
knife azurerm server create `
--azure-resource-group-name rg-chefdeployment `
--azure-storage-account store `
--azure-vm-name chefvm `
--azure-vm-size 'Standard_DS2_v2' `
--azure-service-location 'westus' `
--azure-image-reference-offer 'WindowsServer' `
--azure-image-reference-publisher 'MicrosoftWindowsServer' `
--azure-image-reference-sku '2016-Datacenter' `
--azure-image-reference-version 'latest' `
-x myuser -P myPassword123 `
--tcp-endpoints '80,3389' `
--chef-daemon-interval 1 `
-r "recipe[webserver]"
En el ejemplo anterior se creará una máquina virtual Standard_DS2_v2 con Windows Server 2016 instalado en la
región Oeste de EE. UU. Sustituir sus variables concretas y ejecutar.
NOTE
Mediante la línea de comandos, también estoy automatizando mis reglas de filtro de red de punto de conexión mediante el
parámetro –tcp-endpoints. He abierto los puertos 80 y 3389 para proporcionar acceso a la página web y la sesión de RDP.
Cuando haya ejecutado el comando, vaya a Azure Portal y verá que el equipo comienza a realizar el
aprovisionamiento.
A continuación aparecerá el símbolo del sistema:
Una vez completada la implementación, la dirección IP pública de la nueva máquina virtual se mostrará al finalizar
la implementación; puede copiarla y pegarla en un explorador web y ver el sitio web que ha implementado. Al
implementar la máquina virtual, hemos abierto el puerto 80, por lo que debería estar disponible externamente.
En este ejemplo se utiliza código HTML creativo.
También puede ver el estado del nodo en Chef Manage.
No olvide que también puede conectarse mediante una sesión RDP desde Azure Portal a través del puerto 3389.
Gracias. Empiece hoy su viaje de su infraestructura como código con Azure.
Publicación de una aplicación web ASP.NET en una
máquina virtual de Azure desde Visual Studio
En este documento se describe cómo publicar una aplicación web ASP.NET en una máquina virtual de Azure
mediante la característica de publicación Microsoft Azure Virtual Machines de Visual Studio 2019.
Requisitos previos
A fin de utilizar Visual Studio para publicar un proyecto de ASP.NET en una máquina virtual de Azure, la máquina
virtual debe estar correctamente configurada.
La máquina debe configurarse para ejecutar una aplicación web ASP.NET y tener WebDeploy instalado.
La máquina virtual debe tener un nombre DNS configurado. Para obtener más información, consulte
Creación de un nombre de dominio completo en Azure Portal para una máquina virtual Windows.
Publicación de la aplicación web ASP.NET en la máquina virtual de

Azure con Visual Studio
En la siguiente sección se describe cómo publicar una aplicación web ASP.NET existente en una máquina virtual de
Azure.
1. Abra la solución de la aplicación web en Visual Studio 2019.
2. Haga clic con el botón derecho en el Explorador de soluciones y elija Publicar...
3. Con la flecha situada a la derecha de la página, desplácese por las opciones de publicación hasta que
encuentre Microsoft Azure Virtual Machines.
4. Seleccione el icono Microsoft Azure Virtual Machines y luego Publicar.

5. Elija la cuenta adecuada (con la suscripción de Azure conectada a la máquina virtual).
Si ha iniciado sesión en Visual Studio, la lista de cuentas se completa con todas las cuentas autenticadas.
Si no ha iniciado sesión, o si la cuenta que necesita no aparece, elija "Agregar una cuenta..." y siga las
indicaciones para iniciar sesión.
6. Seleccione la máquina virtual adecuada en la lista de máquinas virtuales existentes.
NOTE
Esta lista puede tardar algún tiempo en completarse.
7. Haga clic en Aceptar para empezar a publicar.
8. Cuando se le pidan las credenciales, proporcione el nombre de usuario y la contraseña de una cuenta de
usuario de la máquina virtual de destino que esté configurada con derechos de publicación. Estas
credenciales normalmente son el nombre de usuario administrador y la contraseña que utilizó al crear la
máquina virtual.
9. Acepte el certificado de seguridad.
10. Vea la ventana de salida para comprobar el progreso de la operación de publicación.
11. Si la publicación se completa correctamente, se iniciará un explorador para abrir la dirección URL del sitio
recién publicado.
Correcto
Ya ha publicado correctamente la aplicación web en una máquina virtual de Azure.
Opciones de la página de publicación

Después de completar al Asistente para publicación, se abrirá la página de publicación en el documento con el
nuevo perfil de publicación seleccionado.
Republicación
Para publicar actualizaciones en la aplicación web, seleccione el botón Publicar en la página de publicación.
Si se le pide, escriba su nombre de usuario y su contraseña.
La publicación se inicia de inmediato.
Modificación de la configuración del perfil de publicación

Para ver y modificar la configuración del perfil de publicación, seleccione Configuración...
La configuración debería ser similar a la que se muestra a continuación:

Guardado de nombre de usuario y contraseña
Evite proporcionar información de autenticación cada vez que publique. Para ello, rellene los campos Nombre
de usuario y Contraseña y seleccione la casilla Guardar contraseña.
Use el botón Validar conexión para confirmar que ha escrito la información correcta.
Implementación en servidor web limpio
Si desea asegurarse de que el servidor web tiene una copia limpia de la aplicación web después de cada
carga y que no quedan otros archivos de una implementación anterior, puede activar la casilla Eliminar
archivos adicionales en el destino en la pestaña Configuración.
Advertencia: la publicación con este parámetro elimina todos los archivos existentes en el servidor web
(directorio wwwroot). Asegúrese de que conoce el estado de la máquina antes de publicar con esta opción
habilitada.
Pasos siguientes
Configuración de la integración o la entrega continua para la implementación automatizada en Azure VM
Para configurar una canalización de entrega continua conAzure Pipelines, consulte Deploy to a Windows Virtual
Machine (Implementación en una máquina virtual Windows).
¿Qué es SQL Server en máquinas virtuales de Azure?
(Windows)
SQL Server en máquinas virtuales de Azure le permite usar versiones completas de SQL Server en la nube sin
tener que administrar todo el hardware local. Las máquinas virtuales con SQL Server también simplifican los
costos de licencia cuando se paga por uso.
Las máquinas virtuales de Azure se ejecutan en distintas regiones geográficas en todo el mundo. También ofrecen
diversos tamaños de máquina. La galería de imágenes de máquina virtual le permite crear una máquina virtual con
SQL Server con la versión, la edición y el sistema operativo correctos. Esto hace que las máquinas virtuales sean
una buena opción para muchas cargas de trabajo de SQL Server diferentes.
Actualizaciones automatizadas
Las máquinas virtuales de Azure con SQL Server pueden usar Automated Patching para programar el intervalo de
tiempo de mantenimiento para la instalación automática de actualizaciones de SQL Server y Windows.
Copias de seguridad automatizadas

Las máquinas virtuales de Azure con SQL Server pueden aprovechar Automated Backup, que crea de forma
regular copias de seguridad de la base de datos en el almacenamiento de blobs. También puede utilizar esta técnica
manualmente. Para más información, consulte Uso de Azure Storage para la copia de seguridad y la restauración
de SQL Server.
Alta disponibilidad
Si requiere alta disponibilidad, considere la posibilidad de configurar grupos de disponibilidad de SQL Server. Esto
implica varias máquinas virtuales de Azure con SQL Server en una red virtual. Puede configurar manualmente la
solución de alta disponibilidad, o puede usar plantillas en Azure Portal para configurarla automáticamente. Para
una introducción a las opciones de alta disponibilidad, consulte Alta disponibilidad y recuperación ante desastres
para SQL Server en máquinas virtuales de Azure.
Rendimiento
Las máquinas virtuales de Azure ofrecen tamaños de máquina diferentes para satisfacer las distintas demandas de
carga de trabajo. Las máquinas virtuales de SQL también proporcionan la configuración automatizada de
almacenamiento, que está optimizada para cumplir con los requisitos de rendimiento. Para más información acerca
de cómo configurar el almacenamiento para las máquinas virtuales de SQL, consulte Configuración del
almacenamiento para máquinas virtuales de SQL Server. Para ajustar el rendimiento, consulte Procedimientos
recomendados para mejorar el rendimiento de SQL Server en Azure Virtual Machines.
Introducción a máquinas virtuales con SQL

Para empezar, elija una imagen de máquina virtual con SQL Server con la versión, la edición y el sistema operativo
requeridos. Las secciones siguientes proporcionan vínculos directos a Azure Portal para las imágenes de la galería
de máquinas virtuales de SQL Server.
TIP
Para conocer los precios de las imágenes de SQL, consulte la Guía de precios para máquinas virtuales de Azure con SQL
Server.
Pago por uso

En la tabla siguiente se proporciona la matriz de imágenes de SQL SErver de pago por uso.
VERSIÓN SISTEMA OPERATIVO EDITION
SQL Server 2017 Windows Server 2016 Enterprise, Standard, Web, Express,
Developer
SQL Server 2016 SP2 Windows Server 2016 Enterprise, Standard, Web, Express,
Developer
SQL Server 2014 SP2 Windows Server 2012 R2 Enterprise, Standard, Web, Express
SQL Server 2012 SP4 Windows Server 2012 R2 Enterprise, Standard, Web, Express
SQL Server 2008 R2 SP3 Windows Server 2008 R2 Enterprise, Standard, Web, Express
Para ver las imágenes de máquinas virtuales Linux con SQL Server disponibles, consulte Overview of SQL Server
on Azure Virtual Machines (Linux) [Introducción a SQL Server en máquinas virtuales de Azure (Linux)].
NOTE
Ya puede cambiar el modelo de licencias de una máquina virtual con SQL Server de pago por uso para usar su propia licencia.
Para más información, consulte Modificación del modelo de licencia para una máquina virtual de SQL en Azure.
Traiga su propia licencia

También puede traer su propia licencia (BYOL ). En este escenario, solo paga por la máquina virtual sin ningún
cargo adicional de licencia de SQL Server. Aportar su propia licencia puede ahorrar dinero con el tiempo en cargas
de trabajo de producción continuas. Para más información, consulte Pricing guidance for SQL Server Azure VMs
(Guía de precios de máquinas virtuales de Azure con SQL Server).
Para usar su propia licencia, puede convertir una VM con SQL de pago por uso existente, o bien implementar una
imagen con {BYOL } con prefijo. Para más información acerca de cómo cambiar el modelo de licencia entre pago
por uso y BYOL, consulte How to change the licensing model for a SQL VM (Cambio del modelo de licencia de
una máquina virtual con SQL ).
VERSIÓN SISTEMA OPERATIVO EDITION
SQL Server 2017 Windows Server 2016 Enterprise BYOL, Standard BYOL
SQL Server 2016 SP2 Windows Server 2016 Enterprise BYOL, Standard BYOL
SQL Server 2014 SP2 Windows Server 2012 R2 Enterprise BYOL, Standard BYOL
SQL Server 2012 SP4 Windows Server 2012 R2 Enterprise BYOL, Standard BYOL
Es posible implementar una imagen anterior de SQL Server que no esté disponible en Azure Portal mediante
PowerShell. Para ver todas las imágenes disponibles con PowerShell, utilice el comando siguiente:
Get-AzVMImageOffer -Location $Location -Publisher 'MicrosoftSQLServer'
Para más información acerca de cómo implementar máquinas virtuales con SQL Server mediante PowerShell,
consulte Aprovisionamiento de máquinas virtuales de SQL Server con Azure PowerShell.
Después de crear la máquina virtual con SQL Server, conéctese a ella desde aplicaciones o herramientas tales
como SQL Server Management Studio (SSMS ). Consulte las instrucciones en Conexión a una máquina virtual de
Azure con SQL Server (Resource Manager).
Migración de los datos
Si tiene una base de datos existente, debe moverla a la máquina virtual de SQL recién aprovisionada. Para ver una
lista de las opciones de migración e instrucciones, consulte Migración de una Base de datos SQL Server a SQL
Server en una máquina virtual de Azure.
Creación y administración de recursos de Azure SQL con Azure Portal

Azure Portal proporciona una sola página donde puede administrar todos los recursos de Azure SQL, incluidas las
máquinas virtuales de SQL.
Para acceder a la página Recursos de Azure SQL, seleccione Azure SQL en el menú de la izquierda de Azure
Portal. Si Azure SQL no está en la lista, seleccione Todos los servicios y, a continuación, escriba Azure SQL en el
cuadro de búsqueda.
NOTE
Azure SQL proporciona una manera rápida y sencilla de acceder a todas las bases de datos SQL, grupos elásticos, servidores
de bases de datos, instancias administradas de SQL y máquinas virtuales SQL. SQL de Azure no es un servicio ni un recurso.
Para administrar los recursos existentes, seleccione el elemento deseado en la lista. Para crear nuevos recursos de
Azure SQL, seleccione + Agregar.
Después de seleccionar + Agregar, vea información adicional sobre las diferentes opciones al seleccionar Mostrar
detalles en cualquier icono.
Para obtener información, consulte:

Creación de una base de datos única
Creación de un grupo elástico
Creación de una instancia administrada
Creación de una máquina virtual SQL
Directiva de actualización de imagen de máquina virtual de SQL

Azure solo mantiene una imagen de máquina virtual para cada combinación admitida de sistema operativo,
versión y edición. Esto significa que a lo largo del tiempo se actualizan las imágenes y las más antiguas se eliminan.
Para más información, consulte la sección Imágenes de las preguntas más frecuentes sobre máquinas virtuales de
SQL Server.
Programa para la mejora de la experiencia del usuario (CEIP)

De manera predeterminada, el Programa para la mejora de la experiencia del cliente (CEIP ) está habilitado. Esto
permitirá enviar periódicamente informes a Microsoft para ayudar a mejorar SQL Server. No hay ninguna tarea de
administración requerida relacionada con el CEIP, a menos que desee deshabilitarlo después del
aprovisionamiento. Puede personalizar o deshabilitar el CEIP mediante la conexión a la máquina virtual a través
del escritorio remoto. A continuación, ejecute la utilidad Informes de uso y errores de SQL Server . Siga las
instrucciones para deshabilitar los informes. Para más información acerca de la recopilación de datos, vea la
declaración de privacidad de SQL Server.
Productos y servicios relacionados

Máquinas virtuales Windows
Información general de Virtual Machines
Storage
Introducción a Microsoft Azure Storage
Redes
Información general sobre Virtual Network
Direcciones IP en Azure
Crear un nombre de dominio completo en el Portal de Azure
SQL
Documentación de SQL Server
Comparación de Azure SQL Database
Pasos siguientes
Introducción a SQL Server en máquinas virtuales de Azure:
Creación de una máquina virtual con SQL Server en Azure Portal
Obtenga respuestas a las preguntas más habituales acerca de las máquinas virtuales con SQL:
Preguntas más frecuentes sobre SQL Server en Azure Virtual Machines
Instalación y configuración de MongoDB en una
máquina virtual Windows en Azure
MongoDB es una conocida base de datos NoSQL de código abierto y alto rendimiento. Este artículo le guía por la
instalación y configuración de MongoDB en una máquina virtual (VM ) Windows Server 2016 en Azure. También
es posible instalar MongoDB en una máquina virtual Linux en Azure.
Requisitos previos
Antes de instalar y configurar MongoDB, es preciso crear una máquina virtual y lo ideal sería agregarle un disco de
datos. Consulte los artículos siguientes para crear una máquina virtual y agregar un disco de datos:
Cree una máquina virtual de Windows Server mediante Azure Portal o Azure PowerShell.
Adjunte un disco de datos a una máquina virtual de Windows Server mediante Azure Portal o Azure
PowerShell.
Para empezar a instalar y configurar MongoDB, inicie sesión en la máquina virtual con Windows Server mediante
Escritorio remoto.
Instalación de MongoDB
IMPORTANT
Las características de seguridad de MongoDB, como la vinculación de direcciones IP y la autenticación, no se encuentran
habilitadas de forma predeterminada. Las características de seguridad deben habilitarse antes de implementar MongoDB en
un entorno de producción. Para más información, consulte MongoDB Security and Authentication (Seguridad y autenticación
de MongoDB).
1. Después de conectarse a la máquina virtual mediante Escritorio remoto, abra Internet Explorer desde la
barra de tareas.
2. Seleccione Usar la configuración recomendada de compatibilidad, privacidad y seguridad la
primera vez que se abra Internet Explorer y haga clic en Aceptar.
3. De forma predeterminada está habilitada la configuración de seguridad mejorada de Internet Explorer.
Agregue el sitio web de MongoDB a la lista de sitios permitidos:
Seleccione el icono Herramientas de la esquina superior derecha.
En Opciones de Internet, seleccione la pestaña Seguridad y, luego, el icono Sitios de confianza.
Haga clic en el botón Sitios. Agregue https://*.mongodb.com a la lista de sitios de confianza y, luego,
cierre el cuadro de diálogo.
4. Vaya a la página de descargas de MongoDB (https://www.mongodb.com/downloads).
5. Si es necesario,, seleccione la edición Community Server y, luego, seleccione la versión estable más
reciente para Windows Server 2008 R2 de 64 bits y posterior. Para descargar el instalador, haga clic en
DOWNLOAD (msi) (DESCARGAR ).
Cuando se haya completado la descarga, ejecute al instalador.

6. Lee y acepte los términos de la licencia. Cuando se le pida, seleccione Complete (Completar) instalación.
7. Si quiere, puede elegir también instalar Compass, una interfaz gráfica para MongoDB.
8. En la última pantalla, haga clic en Install (Instalar).
Configuración de la máquina virtual y MongoDB

1. El instalador de MongoDB no actualiza las variables path. Sin la ubicación bin de MongoDB en la variable
path, será preciso especificar la ruta de acceso completa cada vez que se use un archivo ejecutable de
MongoDB. Para agregar la ubicación a la variable path:
Haga clic con el botón derecho en el menú Inicio y seleccione Sistema.
Haga clic en la pestaña Configuración avanzada del sistema y luego en Variables de entorno.
En Variables del sistema, seleccione Path, y, luego, haga clic en Editar.
Agregue la ruta de acceso a la carpeta bin de MongoDB. MongoDB se suele instalar en C:\Archivos
de programa\MongoDB. Compruebe la ruta de instalación en la máquina v. En el ejemplo siguiente
se agrega la ubicación de instalación de MongoDB predeterminada a la variable PATH :
;C:\Program Files\MongoDB\Server\3.6\bin
NOTE
No olvide agregar el signo inicial de punto y coma ( ; ) para indicar que va a agregar una ubicación a la
variable PATH .
2. Cree los directorios de registro y datos de MongoDB en el disco de datos. En el menú Inicio, seleccione
Símbolo del sistema. En los ejemplos siguientes los directorios se crean en la unidad F:
mkdir F:\MongoData
mkdir F:\MongoLogs
3. Inicie una instancia de MongoDB con el siguiente comando y ajuste la ruta de acceso a los directorios de
registro y de datos en consecuencia:
mongod --dbpath F:\MongoData\ --logpath F:\MongoLogs\mongolog.log
MongoDB puede tardar varios minutos en asignar los archivos de diario y comenzar la escucha de
conexiones. Todos los mensajes de registro se dirigen al archivo F:\MongoLogs\mongolog.log cuando el
servidor mongod.exe se inicia y asigna los archivos de diario.
NOTE
El símbolo del sistema permanece centrado en esta tarea mientras se ejecuta la instancia de MongoDB. Deje la
ventana de símbolo del sistema abierta para continuar con la ejecución de MongoDB. O bien, instale MongoDB como
servicio, como se detalla en el paso siguiente.
4. Para una experiencia más sólida de MongoDB, instale mongod.exe como servicio. La creación de un servicio
significa que no es preciso dejar un símbolo de sistema en ejecución cada vez que se desee utilizar
MongoDB. Cree el servicio como se indica a continuación y ajuste la ruta de acceso a los directorios de
datos y de registro según en consecuencia:
mongod --dbpath F:\MongoData\ --logpath F:\MongoLogs\mongolog.log --logappend --install
El comando anterior crea un servicio denominado MongoDB con la descripción "Mongo DB". También se
especifican los parámetros siguientes:
La opción --dbpath especifica la ubicación del directorio de datos.
La opción --logpath debe usarse para especificar un archivo de registro, ya que el servicio en ejecución
no dispone de una ventana de comandos que muestre la salida.
La opción --logappend especifica que un reinicio del servicio provoca que la salida se anexe al archivo de
registro existente.
Para iniciar el servicio de MongoDB, ejecute el siguiente comando:
net start MongoDB
Para más información acerca de cómo crear el servicio MongoDB, consulte Configure a Windows Service
for MongoDB (Configuración de un servicio de Windows para MongoDB ).
Prueba de la instancia de MongoDB

Con MongoDB ejecutándose como una instancia individual o instalado como un servicio, ya puede comenzar la
creación y uso de las bases de datos. Para iniciar el shell administrativo de MongoDB, abra otra ventana del
símbolo del sistema en el menú Inicio y escriba el siguiente comando:
mongo
Puede enumerar las bases de datos con el comando db . Inserte algunos datos como sigue:
db.foo.insert( { a : 1 } )
Busque datos como sigue:
db.foo.find()
La salida es similar a la del ejemplo siguiente:
{ "_id" : "ObjectId("57f6a86cee873a6232d74842"), "a" : 1 }
Salga de la consola de mongo como se indica a continuación:
exit
Configuración de reglas del grupo de seguridad de red y del firewall

Ahora que MongoDB ya está instalado y ejecutándose, abra un puerto en Firewall de Windows para poder
conectarse de forma remota a MongoDB. Para crear una nueva regla de entrada para permitir el puerto TCP
27017, abra un símbolo del sistema administrativo de PowerShell y escriba el siguiente comando:
New-NetFirewallRule `
-DisplayName "Allow MongoDB" `
-Protocol TCP `
-LocalPort 27017 `
-Action Allow
También puede crear la regla mediante la herramienta de administración gráfica Firewall de Windows con
seguridad avanzada. Cree una nueva regla de entrada para permitir el puerto TCP 27017.
Si es necesario, cree una regla de grupo de seguridad de red para permitir el acceso a MongoDB desde fuera de la
subred de la red virtual de Azure existente. Las reglas del grupo de seguridad de red se pueden crear mediante
Azure Portal o Azure PowerShell. Igual que sucede con las reglas de Firewall de Windows, permita el puerto TCP
27017 en la interfaz de red virtual de la máquina virtual con MongoDB.
NOTE
El puerto TCP 27017 es el puerto predeterminado que usa MongoDB. Para cambiarlo, use el parámetro --port al iniciar
mongod.exe manualmente o desde un servicio. Si cambia el puerto, asegúrese de actualizar las reglas de Firewall de
Windows y del grupo de seguridad de red en los pasos anteriores.
Pasos siguientes
En este tutorial ha aprendido a instalar y configurar MongoDB en una máquina virtual Windows. Ahora puede
acceder a MongoDB en una máquina virtual Windows siguiendo los temas avanzados de la documentación de
MongoDB.
Uso de Azure para hospedar y ejecutar escenarios de
carga de trabajo de SAP
Cuando utiliza Microsoft Azure, puede ejecutar de forma confiable los escenarios y las cargas de trabajo de SAP
críticas en una plataforma compatible, ampliable y de uso demostrado en la empresa. Consigue la escalabilidad, la
flexibilidad y el ahorro de costos de Azure. Con la ampliación de la asociación entre Microsoft y SAP, puede
ejecutar las aplicaciones SAP en escenarios de desarrollo, pruebas y producción en Azure y serán totalmente
compatibles. De SAP NetWeaver a SAP S/4HANA, de BI de SAP en Linux a Windows y de SAP HANA a SQL, lo
cubrimos todo.
Además de hospedar escenarios de SAP NetWeaver con los diferentes DBMS en Azure, puede hospedar otros
escenarios de cargas de trabajo de SAP, como BI de SAP en Azure.
La unicidad de Azure para SAP HANA es una oferta que distingue a Azure. Para habilitar el hospedaje de
escenarios de SAP con más demanda de recursos de memoria y CPU que implican a SAP HANA, Azure ofrece el
uso de hardware de reconstrucción completa dedicado para el cliente. Use esta solución para ejecutar las
implementaciones de SAP HANA que requieren hasta 24 TB (120 TB de escalabilidad horizontal) de memoria para
S/4HANA u otra carga de trabajo de SAP HANA.
El hospedaje de escenarios de carga de trabajo de SAP en Azure también puede crear requisitos de integración de
identidades y de inicio de sesión único. Esta situación puede producirse al usar Azure Active Directory (Azure AD )
para conectar diferentes componentes y ofertas de software como servicio (SaaS ) o plataforma como servicio
(PaaS ) de SAP. En la sección "Integración de identidades de AAD SAP e inicio de sesión único" se describe y
documenta una lista de estos escenarios de integración e inicio de sesión único con entidades de Azure AD y SAP.
Cambios en la sección de cargas de trabajo de SAP

Al final de este artículo se enumeran los cambios en los documentos de la sección sobre cargas de trabajo de SAP
en Azure.
SAP HANA en Azure (instancias grandes)

Una serie de documentos le guían a través de SAP HANA en Azure (instancias grandes) o, para abreviar, las
instancias grandes de HANA. Para obtener información acerca de las siguientes áreas de las instancias grandes de
HANA, consulte:
Introducción de SAP HANA en Azure (instancias grandes)
Arquitectura de SAP HANA en Azure (instancias grandes)
Infraestructura y conectividad con SAP HANA en Azure (instancias grandes)
Instalación de SAP HANA en Azure (instancias grandes)
Alta disponibilidad y recuperación ante desastres de SAP HANA en Azure (instancias grandes)
Supervisión de SAP HANA en Azure (Instancias grandes)
Pasos siguientes:
Consulte la Introducción y arquitectura de SAP HANA en Azure (instancias grandes).
SAP HANA en máquinas virtuales de Azure

Esta sección de la documentación trata diferentes aspectos de SAP HANA. Antes debe estar familiarizado con los
principales servicios de Azure que proporcionan servicios básicos de IaaS de Azure. Por lo tanto, necesita conocer
el proceso, almacenamiento y redes de Azure. Muchos de estos temas se tratan en la guía de planeamiento de
Azure relacionada con SAP NetWeaver.
Para obtener información sobre HANA en Azure, consulte los siguientes artículos y sus artículos secundarios:
Inicio rápido: instalación manual de una única instancia de SAP HANA en máquinas virtuales de Azure
Implementación de SAP S/4HANA o BW/4HANA en Azure
Configuraciones y operaciones de infraestructura de SAP HANA en Azure
Alta disponibilidad de SAP HANA para máquinas virtuales de Azure
Disponibilidad de SAP HANA dentro de una región de Azure
Disponibilidad de SAP HANA entre regiones de Azure
Alta disponibilidad de SAP HANA en máquinas virtuales de Azure
Guía de copia de seguridad de SAP HANA en Azure Virtual Machines
Azure Backup de SAP HANA en el nivel de archivo
Copia de seguridad de SAP HANA basada en instantáneas de almacenamiento
SAP NetWeaver implementado en máquinas virtuales de Azure

En esta sección se incluye documentación sobre la planeación e implementación para SAP NetWeaver y Business
One en Azure. La documentación se centra en los conceptos básicos y el uso de las bases de datos no
perteneciente a HANA con una carga de trabajo de SAP en Azure. Los documentos y los artículos sobre alta
disponibilidad también son la base para la alta disponibilidad de HANA en Azure como, por ejemplo:
SAP Business One en Azure Virtual Machines
Implementación de SAP IDES EHP7 SP3 para SAP ERP 6.0 en Azure
Ejecución de SAP NetWeaver en máquinas virtuales de SUSE Linux de Microsoft Azure
Implementación y planeamiento de Azure Virtual Machines para SAP NetWeaver
Implementación de Azure Virtual Machines para SAP NetWeaver
Protección de la implementación de una aplicación SAP NetWeaver de niveles múltiples mediante Site
Recovery
Conector de SAP LaMa para Azure
Para obtener información sobre las bases de datos no pertenecientes a HANA bajo una carga de trabajo de SAP en
Azure, consulte:
Consideraciones para la implementación de DBMS de Azure Virtual Machines para la carga de trabajo de SAP
Implementación de DBMS de Azure Virtual Machines de SQL Server para la carga de trabajo de SAP
NetWeaver
Implementación de DBMS de Azure Virtual Machines de Oracle para una carga de trabajo de SAP
Implementación de DBMS de Azure Virtual Machines de IBM DB2 para una carga de trabajo de SAP
Implementación de DBMS de Azure Virtual Machines de SAP ASE para una carga de trabajo de SAP
Implementación de SAP MaxDB, liveCache y del servidor de contenido en máquinas virtuales de Azure
Para obtener información sobre las bases de datos de SAP HANA en Azure, consulte la sección "SAP HANA en
máquinas virtuales de Azure".
Para obtener información sobre la alta disponibilidad de una carga de trabajo de SAP en Azure, consulte:
Alta disponibilidad de Azure Virtual Machines para SAP NetWeaver
Este documento apunta a muchos otros documentos de arquitectura y escenario. En documentos posteriores del
escenario, se proporcionan vínculos a documentos técnicos detallados que explican la implementación y
configuración de los distintos métodos de alta disponibilidad. Los distintos documentos que muestran cómo
establecer y configurar la alta disponibilidad para cargas de trabajo de SAP NetWeaver comprenden a los sistemas
operativos Linux y Windows.
Para obtener información sobre la integración entre Azure Active Directory (AAD ), los servicios de SAP y el inicio
de sesión único, consulte:
Tutorial: Integración de Azure Active Directory con SAP Cloud for Customer
Tutorial: Integración de Azure Active Directory con SAP Cloud Platform Identity Authentication
Tutorial: Integración de Azure Active Directory con SAP Cloud Platform
Tutorial: Integración de Azure Active Directory con SAP NetWeaver
Tutorial: Integración de Azure Active Directory con SAP Business ByDesign
Tutorial: Integración de Azure Active Directory con SAP HANA
Your S/4HANA environment: Fiori Launchpad SAML single sign-on with Azure AD (Entorno S/4HANA: inicio
de sesión único basado en SAML para Fiori Launchpad con Azure AD )
Para obtener información sobre la integración de servicios de Azure en los componentes de SAP, consulte:
Uso de SAP HANA en Power BI Desktop
DirectQuery y SAP HANA
Uso del conector SAP BW en Power BI Desktop
Azure Data Factory ofrece integración de datos de SAP HANA y Business Warehouse
Registro de cambios
12/11/2019: Publicación de Alta disponibilidad de SAP NetWeaver en Windows con Azure NetApp Files (SMB )
08/11/2019: Cambios en Alta disponibilidad de SAP HANA en máquinas virtuales de Azure en SUSE Linux
Enterprise Server, Configuración de la replicación del sistema SAP HANA en máquinas virtuales de Azure, Alta
disponibilidad para SAP NetWeaver en máquinas virtuales de Azure en SUSE Linux Enterprise Server para
SAP Applications, Alta disponibilidad de SAP NetWeaver en VM de Azure en SUSE Linux Enterprise Server
con Azure NetApp Files para las aplicaciones de SAP, Alta disponibilidad de Azure Virtual Machines para SAP
NetWeaver en Red Hat Enterprise Linux, Alta disponibilidad de Azure Virtual Machines para SAP NetWeaver
en Red Hat Enterprise Linux con Azure NetApp Files para aplicaciones SAP, Alta disponibilidad para NFS en
máquinas virtuales de Azure en SUSE Linux Enterprise Server, GlusterFS en máquinas virtuales de Azure de
Red Hat Enterprise Linux para SAP NetWeaver para recomendar el equilibrador de carga estándar de Azure
08/11/2019: Cambios en Lista de comprobación de planeamiento e implementación de cargas de trabajo de
SAP en Azure para aclarar la recomendación de cifrado
04/11/2019: Cambios en Configuración de Pacemaker en SUSE Linux Enterprise Server en Azure para crear el
clúster directamente con la configuración de unidifusión.
29/10/2019: Publicación de Conectividad del punto de conexión público para las máquinas virtuales que usan
Azure Standard Load Balancer en escenarios de alta disponibilidad de SAP.
25/10/2019: Cambios en Configuraciones de almacenamiento de máquina virtual de Azure en SAP HANA y en
Escalabilidad horizontal de SAP HANA con nodo en espera en máquinas virtuales de Azure con Azure NetApp
Files en SUSE Linux Enterprise Server para clarificar el protocolo NFS para SAP HANA o para volúmenes
compartidos.
22/10/2019: Cambio en Alta disponibilidad de SAP NetWeaver en VM de Azure en SUSE Linux Enterprise
Server con Azure NetApp Files para las aplicaciones de SAP, Alta disponibilidad para SAP NetWeaver en
máquinas virtuales de Azure en SUSE Linux Enterprise Server para aplicaciones de SAP, Alta disponibilidad
para NFS en máquinas virtuales de Azure en SUSE Linux Enterprise Server, Configuración de Pacemaker en
SUSE Linux Enterprise Server en Azure, Alta disponibilidad de IBM Db2 LUW en máquinas virtuales de Azure
en SUSE Linux Enterprise Server con Pacemakery Alta disponibilidad de SAP HANA en máquinas virtuales de
Azure en SUSE Linux Enterprise Server para la protección de la detección del equilibrador de carga de Azure.
Cambios en la sección ANF y la sección de encabezado en Configuraciones de almacenamiento de máquinas
virtuales de Azure en SAP HANA
21/10/2019: Publicación de SAP HANA scale-out with standby node on Azure VMs with Azure NetApp Files
on SLES (Escalabilidad horizontal de SAP HANA con nodo en espera en máquinas virtuales de Azure con
Azure NetApp Files en SLES )
16/10/2019: Corrección de vínculos rotos en Copia de seguridad y restauración
16/10/2019: Cambio en el sistema operativo mínimo recomendado de SLES 12 SP3 a SLES 12 SP4 en Alta
disponibilidad de IBM Db2 LUW en máquinas virtuales de Azure en SUSE Linux Enterprise Server con
Pacemaker
11/10/2019: Cambios en las configuraciones de almacenamiento de disco Ultra e introducción de ANF en
Configuraciones de almacenamiento de máquinas virtuales de Azure en SAP HANA
01/10/2019: Cambio en los gráficos de Grupos de selección de ubicación de proximidad de Azure para una
latencia de red óptima con aplicaciones SAP para conseguir mayor claridad.
01/10/2019: Cambio en Configuraciones y operaciones de infraestructura de SAP HANA en Azure para
corregir instrucciones relacionadas con el recurso compartido NFS de alta disponibilidad para /hana/shared.
28/09/2019: Cambio en Configuración de Pacemaker en Red Hat Enterprise Linux en Azure para acarar que no
se admite SBD como mecanismo de barrera en los clústeres RHEL.
17/09/2019: Cambio en la guía de planeación e implementación de NetWeaver para unificar los términos en
torno a la extensión de máquina virtual para SAP
22/08/2019: Cambios en Configuración de Pacemaker en SUSE Linux Enterprise Server en Azure para
actualizar las direcciones URL para la creación de roles personalizados.
16/08/2019: Cambios en Configuración de Pacemaker en Red Hat Enterprise Linux en Azure para recordar a
los clientes que si se actualizan a la nueva versión del agente de barrera de Azure, actualicen las acciones en el
rol personalizado.
15/08/2019: Cambios en Configuraciones de almacenamiento de máquinas virtuales de Azure en SAP HANA
para reflejar la disponibilidad general de discos Ultra (anteriormente SSD Ultra)
01/08/2019: Cambios en la Configuración de Pacemaker en SUSE Linux Enterprise Server en Azure para
integrar los cambios específicamente para SLES 15
23/07/2019: Cambios en Agrupación de una instancia de ASCS/SCS de SAP en un clúster de conmutación por
error de Windows con un recurso compartido de archivos en Azure para reflejar la compatibilidad de Espacio
de almacenamiento directo con Azure Site Recovery Services
14/07/2019: Versión de Grupos de selección de ubicación de proximidad de Azure para una latencia de red
óptima con aplicaciones SAP
11/07/2019: Cambios en varios documentos que tratan HANA Instancias grandes para cubrir la revisión 4 de
HANA Instancias grandes
09/07/2019: Versión de la nueva guía para IBM Db2 HADR en Red Hat Enterprise Server
13/06/2019: Versión de Alta disponibilidad para SAP NetWeaver en Red Hat Enterprise Linux con Azure
NetApp Files para aplicaciones SAP
Creación de clústeres de MATLAB Distributed
Computing Server en Máquinas virtuales de Azure
Utilice Máquinas virtuales de Microsoft Azure para crear uno o más clústeres de MATLAB Distributed Computing
Server con el fin de ejecutar sus cargas de trabajo MATLAB paralelas de proceso intensivo. Instale el software
MATLAB Distributed Computing Server en una máquina virtual para usarlo como una imagen base y usar una
plantilla de inicio rápido de Azure o un script de Azure PowerShell (disponible en GitHub) para implementar y
administrar el clúster. Después de la implementación, conéctese al clúster para ejecutar sus cargas de trabajo.
Información acerca de MATLAB y MATLAB Distributed Computing

Server
La plataforma MATLAB está optimizada para solucionar problemas científicos y de ingeniería. Los usuarios de
MATLAB con tareas de simulación y procesamiento de datos a gran escala pueden utilizar productos de
computación en paralelo de MathWorks para acelerar sus cargas de trabajo de proceso intensivo, ya que
aprovechan las ventajas de los clústeres de proceso y los servicios en malla. Parallel Computing Toolbox permite a
los usuarios de MATLAB usar las aplicaciones en paralelo y aprovechar las ventajas de los procesadores de núcleo
múltiple, GPU y clústeres de proceso. MATLAB Distributed Computing Server permite a los usuarios de MATLAB
usar muchos equipos en un clúster de proceso.
Mediante el uso de máquinas virtuales de Azure, puede crear clústeres de MATLAB Distributed Computing Server,
que tienen los mismos mecanismos disponibles para enviar el trabajo paralelo como clústeres locales; por ejemplo,
trabajos interactivos, trabajos por lotes, tareas independientes y tareas de comunicación. El uso de Azure junto con
la plataforma MATLAB tiene muchas ventajas en comparación con el aprovisionamiento y uso tradicional de
hardware local: diversos tamaños de máquina virtual, creación de clústeres a petición para pagar solo por los
recursos de proceso que utilice y la capacidad de probar modelos a escala.
Requisitos previos
Equipo cliente : necesitará un equipo cliente basado en Windows para comunicarse con Azure y el clúster de
MATLAB Distributed Computing Server después de la implementación.
Azure PowerShell : consulte Cómo instalar y configurar Azure PowerShell para instalarlo en el equipo cliente.
Suscripción de Azure : si no tiene ninguna, puede crear una cuenta gratuita en un par de minutos. En los
clústeres más grandes, considere la posibilidad de una suscripción de pago por uso u otras opciones de compra.
Cuota de vCPU: es posible que tenga que aumentar la cuota de vCPU para implementar un clúster grande o
más de un clúster de MATLAB Distributed Computing Server. Para aumentar una cuota, abra una solicitud de
soporte técnico al cliente en línea sin cargo alguno.
Licencias de MATLAB, Parallel Computing Toolbox y MATLAB Distributed Computing Server ; los
scripts asumen que se usa MathWorks Hosted License Manager para todas las licencias.
Software MATLAB Distributed Computing Server : se instalará en una máquina virtual que se utilizará
como la imagen de máquina virtual base para las máquinas virtuales del clúster.
Pasos de alto nivel

Para usar máquinas virtuales de Azure para los clústeres de MATLAB Distributed Computing Server, son
necesarios los siguientes pasos de alto nivel. Hay instrucciones detalladas en la documentación que acompaña a la
plantilla de inicio rápido y scripts en GitHub.
1. Creación de una imagen de máquina virtual base
Descargue e instale el software MATLAB Distributed Computing Server en esta máquina virtual.
NOTE
Este proceso puede tardar un par de horas, pero solo tiene que hacerlo una vez para cada versión de MATLAB
que use.
2. Creación de uno o varios clústeres

Use el script de PowerShell proporcionado o utilice la plantilla de inicio rápido para crear un clúster a
partir de la imagen de máquina virtual base.
Administre los clústeres mediante el script de PowerShell proporcionado, que permite enumerar, pausar,
reanudar y eliminar los clústeres.
Configuraciones de clústeres
Actualmente, el script y la plantilla de creación de clústeres permiten crear una sola topología de MATLAB
Distributed Computing Server. Si lo desea, cree uno o más clústeres adicionales en los que cada clúster tendrá un
número diferente de máquinas virtuales de trabajo, usará diferentes tamaños de máquina virtual, etc.
Clúster y cliente de MATLAB en Azure
El nodo cliente de MATLAB, el nodo de MATLAB Job Scheduler y los nodos de "trabajo" de MATLAB Distributed
Computing Server se configuran como máquinas virtuales de Azure en una red virtual, como se muestra en la
ilustración siguiente.
Para utilizar el clúster, conéctese mediante Escritorio remoto al nodo cliente. El nodo cliente ejecuta el cliente de
MATLAB.
El nodo cliente tiene un recurso compartido de archivos al que tienen acceso todos los trabajadores.
MathWorks Hosted License Manager se usa para las comprobaciones de licencia de todo el software de
MATLAB.
De forma predeterminada, se crea un trabajo de MATLAB Distributed Computing Server por vCPU en las
máquinas virtuales de trabajo, pero se puede especificar cualquier número.
Uso de un clúster de Azure

Como con otros tipos de clústeres de MATLAB Distributed Computing Server, debe usar Cluster Profile Manager
en el cliente de MATLAB (en la máquina virtual del cliente) para crear un perfil de clúster en MATLAB Job
Scheduler.
Pasos siguientes
Para instrucciones detalladas para implementar y administrar clústeres de MATLAB Distributed Computing
Server en Azure, consulte el repositorio GitHub , que contiene las plantillas y los scripts.
Vaya al sitio de MathWorks para ver documentación detallada de MATLAB y MATLAB Distributed Computing
Server.
Imágenes de Visual Studio en Azure
El uso de Visual Studio en una máquina virtual (VM ) de Azure preconfigurada es la manera más fácil y rápida de
tener un entorno de desarrollo que funcione correctamente desde el principio. En Azure Marketplace encontrará
varias imágenes del sistema con distintas configuraciones de Visual Studio.
¿Acaba de llegar a Azure? Creación de una cuenta de Azure gratis.
NOTE
No todas las suscripciones son aptas para implementar imágenes de Windows 10. Para obtener más información, consulte
Uso del cliente Windows en Azure para escenarios de desarrollo y pruebas.
¿Qué configuraciones y versiones están disponibles?

En Azure Marketplace se pueden encontrar imágenes de las versiones principales más recientes:
Visual Studio 2019, Visual Studio 2017 y Visual Studio 2015. Igualmente, para cada versión principal publicada
podrá ver la "versión de lanzamiento original en la Web" (RTW ) y las últimas versiones actualizadas. Cada una de
estas versiones ofrece las ediciones Visual Studio Enterprise y Visual Studio Community. Estas imágenes se
actualizan al menos cada mes para incluir las actualizaciones más recientes de Visual Studio y Windows. Aunque
los nombres de las imágenes siguen siendo los mismos, la descripción de cada imagen incluye la versión del
producto instalada y la fecha inicial de la imagen.
VERSIÓN DE LANZAMIENTO EDICIONES VERSIÓN DEL PRODUCTO
Visual Studio 2019: versión más Enterprise, Community Versión 16.3.0

reciente (16.3)
Visual Studio 2019: RTW Enterprise, Community Versión 16.0.8
Visual Studio 2017: Versión más Enterprise, Community Versión 15.9.16

reciente (v15.9)
Visual Studio 2017: RTW Enterprise, Community Versión 15.0.25
Visual Studio 2015: más reciente Enterprise, Community Versión 14.0.25431.01

(Actualización 3)
NOTE
De acuerdo con la directiva de mantenimiento de Microsoft, ha expirado el mantenimiento de la versión de lanzamiento
original (RTW) de Visual Studio 2015. Visual Studio 2015 Update 3 es la única versión que queda que se ofrece en la línea de
productos de Visual Studio 2015.
Para obtener más información, consulte la Directiva de mantenimiento de Visual Studio.
¿Qué características están instaladas?

Cada imagen contiene el conjunto de características recomendado para esa edición de Visual Studio. Por lo
general, la instalación incluye:
Todas las cargas de trabajo disponibles, incluidos los componentes opcionales recomendados de cada carga de
trabajo
SDK de .NET 4.6.2 y .NET 4.7, paquetes de destino y herramientas de desarrollo
Visual F#
Extensión de GitHub para Visual Studio
Herramientas de LINQ to SQL
La línea de comandos usada para instalar Visual Studio al compilar las imágenes es la siguiente:
vs_enterprise.exe --allWorkloads --includeRecommended --passive ^

add Microsoft.Net.Component.4.7.SDK ^
add Microsoft.Net.Component.4.7.TargetingPack ^
add Microsoft.Net.Component.4.6.2.SDK ^
add Microsoft.Net.Component.4.6.2.TargetingPack ^
add Microsoft.Net.ComponentGroup.4.7.DeveloperTools ^
add Microsoft.VisualStudio.Component.FSharp ^
add Component.GitHub.VisualStudio ^
add Microsoft.VisualStudio.Component.LinqToSql
Si las imágenes no incluyen la característica de Visual Studio que necesita, proporcione comentarios mediante la
herramienta para crear comentarios que se encuentra en la esquina superior derecha de la página.
¿Qué tamaño de VM debería elegir?

Azure ofrece una amplia gama de tamaños de máquina virtual. Dado que Visual Studio es una eficaz aplicación
multiproceso, es recomendable que la máquina virtual tenga un tamaño que pueda incluir al menos dos
procesadores y 7 GB de memoria. Se recomiendan los siguientes tamaños de máquina virtual para las imágenes
de Visual Studio:
Standard_D2_v3
Standard_D2s_v3
Standard_D4_v3
Standard_D4s_v3
Standard_D2_v2
Standard_D2S_v2
Standard_D3_v2
Para obtener más información acerca de los tamaños más recientes de máquinas virtuales, consulte Tamaños de
las máquinas virtuales Windows en Azure.
Con Azure, puede volver a equilibrar su elección inicial mediante la modificación del tamaño de la máquina virtual.
Puede aprovisionar una nueva máquina virtual con un tamaño más adecuado o cambiar el tamaño de la máquina
virtual existente para otro hardware subyacente. Para más información, consulte Cambio de tamaño de una
máquina virtual Windows.
Una vez que la máquina virtual ya está en ejecución, ¿qué es lo

siguiente?
Visual Studio sigue el modelo "traiga su propia licencia" en Azure. Igual que sucede con la instalación en hardware
propietario, uno de los primeros pasos es obtener una licencia para la instalación de Visual Studio. Para
desbloquear Visual Studio, tiene dos opciones:
Iniciar sesión con una cuenta de Microsoft que esté asociada con una suscripción de Visual Studio
Desbloquear Visual Studio con la clave de producto suministrada con la compra inicial
Para más información, consulte Iniciar sesión en Visual Studio y Cómo desbloquear Visual Studio.
¿Cómo puedo guardar la máquina virtual de desarrollo para usarla en

un futuro o trabajar en equipo?
Hay una amplia gama de entornos de desarrollo y, si quiere compilar uno de los entornos más complejos, esto le
supondrá un costo significativo. Con independencia de la configuración del entorno, puede guardar o capturar la
máquina virtual configurada como una "imagen base" para usarla en un futuro o con otros miembros de su equipo.
Luego, al arrancar una nueva máquina virtual, puede aprovisionarla a partir de la imagen base en lugar de la
imagen de Azure Marketplace.
Resumen rápido: use la herramienta de preparación del sistema (Sysprep) y apague la máquina virtual en
ejecución. A continuación, capture (Figura 1 ) la máquina virtual como una imagen mediante la interfaz de usuario
de Azure Portal. Azure guarda el archivo .vhd que contiene la imagen en la cuenta de almacenamiento de su
elección. La nueva imagen se muestra entonces como un recurso de imagen en la lista de recursos de la
suscripción.
(Figura 1 ) Captura de una imagen mediante la interfaz de usuario de Azure Portal.

Para más información, consulte Captura de una imagen administrada de una máquina virtual generalizada en
Azure.
IMPORTANT
No olvide usar Sysprep para preparar la máquina virtual. Si se salta este paso, Azure no podrá aprovisionar la VM desde la
imagen.
NOTE
Almacenar las imágenes le supondrá cierto costo, pero ese costo incremental puede ser insignificante en comparación con los
costos generales de recompilar la máquina virtual desde cero para cada miembro del equipo que necesite una. Por ejemplo,
puede crear y almacenar una imagen de 127 GB durante un mes para que la use el equipo entero y solo le costará una
pequeña cantidad de dinero. Sin embargo, este costo es insignificante si lo comparamos con las horas que debe invertir cada
empleado en compilar y validar un cuadro de desarrollo que esté configurado correctamente y que se pueda usar de forma
individual.
Además, las tareas o tecnologías dedicadas al desarrollo necesitan más escalado, como las variedades referentes a
la configuración de desarrollo y a la configuración de varias máquinas. Puede usar Azure DevTest Labs para crear
recetas que automaticen la construcción de la "imagen maestra". También puede usar DevTest Labs para
administrar directivas de las máquinas virtuales en ejecución de su equipo. Si quiere obtener más información
acerca de DevTest Labs, consulte Uso de Azure DevTest Labs para desarrolladores.
Pasos siguientes
Ahora que ya conoce las imágenes preconfiguradas de Visual Studio, el siguiente paso es crear una nueva máquina
virtual:
Cree una máquina virtual Windows en Azure Portal
Información general sobre las máquinas virtuales Windows
2 minutes to read
2 minutes to read
2 minutes to read
2 minutes to read
2 minutes to read
2 minutes to read
Conexión de un disco a una VM Windows con
PowerShell
En este artículo se explica cómo conectar discos nuevos y existentes a una máquina virtual Windows con
PowerShell.
En primer lugar, revise estas sugerencias:
El tamaño de la máquina virtual controla cuántos discos de datos puede conectar. Para más información,
consulte Tamaños de las máquinas virtuales Linux en Azure.
Para usar discos SSD Premium, necesitará un tipo de VM con Premium Storage habilitado, como el de las
máquinas virtuales de las series DS o GS.
En este artículo se usa PowerShell dentro de Azure Cloud Shell, que se actualiza constantemente a la versión
más reciente. Para abrir Cloud Shell, seleccione Pruébelo en la esquina superior de cualquier bloque de código.
Incorporación de un disco de datos vacío a una máquina virtual

En este ejemplo se muestra cómo agregar un disco de datos vacío a una máquina virtual existente.
Uso de discos administrados
$rgName = 'myResourceGroup'
$vmName = 'myVM'
$location = 'East US'
$dataDiskName = $vmName + '_datadisk1'
$diskConfig = New-AzDiskConfig -SkuName $storageType -Location $location -CreateOption Empty -DiskSizeGB 128
$dataDisk1 = New-AzDisk -DiskName $dataDiskName -Disk $diskConfig -ResourceGroupName $rgName

$vm = Add-AzVMDataDisk -VM $vm -Name $dataDiskName -CreateOption Attach -ManagedDiskId $dataDisk1.Id -Lun 1
Update-AzVM -VM $vm -ResourceGroupName $rgName
Uso de discos administrados en una zona de disponibilidad

Para crear un disco en una zona de disponibilidad, use New -AzDiskConfig con el parámetro -Zone . En el
siguiente ejemplo se crea un disco en la zona 1.
$vmName = 'myVM'
$location = 'East US 2'
$dataDiskName = $vmName + '_datadisk1'
$diskConfig = New-AzDiskConfig -SkuName $storageType -Location $location -CreateOption Empty -DiskSizeGB 128
-Zone 1
$dataDisk1 = New-AzDisk -DiskName $dataDiskName -Disk $diskConfig -ResourceGroupName $rgName

$vm = Add-AzVMDataDisk -VM $vm -Name $dataDiskName -CreateOption Attach -ManagedDiskId $dataDisk1.Id -Lun 1
Initialize the disk

Después de agregar un disco vacío, debe inicializarlo. Para hacerlo, puede iniciar sesión en una VM y usar la
administración de discos. Si habilitó WinRM y un certificado en la VM cuando la creó, puede usar PowerShell
remoto para inicializar el disco. También puede utilizar una extensión de script personalizada:
$location = "location-name"
$scriptName = "script-name"
$fileName = "script-file-name"
Set-AzVMCustomScriptExtension -ResourceGroupName $rgName -Location $locName -VMName $vmName -Name
$scriptName -TypeHandlerVersion "1.4" -StorageAccountName "mystore1" -StorageAccountKey "primary-key" -
FileName $fileName -ContainerName "scripts"
El archivo de script puede contener código para inicializar los discos, por ejemplo:
$disks = Get-Disk | Where partitionstyle -eq 'raw' | sort number
$letters = 70..89 | ForEach-Object { [char]$_ }

$count = 0
$labels = "data1","data2"
foreach ($disk in $disks) {

$driveLetter = $letters[$count].ToString()
$disk |
Initialize-Disk -PartitionStyle MBR -PassThru |
New-Partition -UseMaximumSize -DriveLetter $driveLetter |
Format-Volume -FileSystem NTFS -NewFileSystemLabel $labels[$count] -Confirm:$false -Force
$count++
}
Incorporación de un disco de datos existente a una VM

También puede conectar un disco administrado existente a una máquina virtual como un disco de datos.
$vmName = "myVM"
$dataDiskName = "myDisk"
$disk = Get-AzDisk -ResourceGroupName $rgName -DiskName $dataDiskName
$vm = Add-AzVMDataDisk -CreateOption Attach -Lun 0 -VM $vm -ManagedDiskId $disk.Id

Pasos siguientes
También puede implementar discos administrados mediante plantillas. Para más información, consulte Uso de
Managed Disks en plantillas de Azure Resource Manager o la plantilla de inicio rápido para implementar varios
discos de datos.
Conexión de un disco de datos administrado a una
máquina virtual Windows en Azure Portal
En este artículo se muestra cómo conectar un nuevo disco de datos administrado a una máquina virtual
Windows en Azure Portal. El tamaño de la máquina virtual determina el número de discos que se puede
conectar. Para más información, consulte Tamaños de las máquinas virtuales Linux en Azure.
Agregar un disco de datos

1. En Azure Portal, en el menú de la izquierda, seleccione Máquinas virtuales.
2. Seleccione una máquina virtual de la lista.
3. En la página Máquina virtual, seleccione Discos.
4. En la página Discos, seleccione Agregar disco de datos.
5. En la lista desplegable para el nuevo disco, seleccione Crear disco.
6. En la página Crear disco administrado, escriba un nombre para el disco y ajuste las demás opciones de
configuración según sea necesario. Seleccione Crear cuando haya terminado.
7. En la página Discos, seleccione Guardar para guardar la configuración del nuevo disco de la máquina
virtual.
8. Una vez que Azure crea el disco y lo asocia a la máquina virtual, el nuevo disco aparece en la configuración
de disco de la máquina virtual en el apartado Discos de datos.
Inicio de un nuevo disco de datos

1. Conéctese a la máquina virtual.
2. Seleccione el menú Inicio de Windows en la máquina virtual en ejecución y escriba diskmgmt.msc en el
cuadro de búsqueda. Se abre la consola Administración de discos.
3. Administración de discos reconocerá que hay un nuevo disco sin inicializar y se abrirá la ventana
Inicializar disco.
4. Asegúrese de que el nuevo disco está seleccionado y seleccione Aceptar para inicializarlo.
5. El nuevo disco aparecerá como sin asignar. Haga clic con el botón derecho en cualquier lugar del disco y
seleccione Nuevo volumen simple. Se abre la ventana Asistente para nuevo volumen simple.
6. Siga los pasos del asistente, conserve todos los valores predeterminados y, cuando haya terminado,
seleccione Finalizar.
7. Cierre Administración de discos.
8. Se abre una ventana emergente que indica que es necesario dar formato al nuevo disco para poder usarlo.
Seleccione Dar formato al disco.
9. En la ventana Dar formato al nuevo disco, active las opciones y seleccione Iniciar.
10. Recibirá una advertencia que indica que al dar formato a los discos se borrarán todos los datos. Seleccione
Aceptar.
11. Cuando se complete el formato, seleccione Aceptar.
Pasos siguientes
También puede conectar un disco de datos mediante PowerShell.
Si la aplicación necesita usar la unidad D: para almacenar datos, puede cambiar la letra de la unidad del
disco temporal de Windows.
Desacoplamiento de un disco de datos de una
máquina virtual de Windows
Cuando ya no necesite un disco de datos que se encuentra conectado a una máquina virtual, puede desconectarlo
fácilmente. Esto quita el disco de la máquina virtual, pero no lo quita del almacenamiento.
WARNING
Si se desconecta un disco, no se elimina automáticamente. Si se ha suscrito a Almacenamiento premium, seguirá acumulando
cargos de almacenamiento por el disco. Para más información, vea Precios y facturación al utilizar Premium Storage.
Si desea volver a usar los datos existentes en el disco, puede acoplarlo de nuevo a la misma máquina virtual (o a
otra).
Desconexión de un disco de datos con PowerShell

También puede quitar un disco de datos en caliente con PowerShell, pero asegúrese de que no haya nada que use
activamente el disco antes de desconectarlo de la máquina virtual.
En este ejemplo, se quita el disco denominado myDisk de la máquina virtual myVM del grupo de recursos
myResourceGroup. Quite primero el disco con el cmdlet Remove-AzVMDataDisk. Luego, actualice el estado de la
máquina virtual con el cmdlet Update-AzVM para completar el proceso de eliminación del disco de datos.
$VirtualMachine = Get-AzVM -ResourceGroupName "myResourceGroup" -Name "myVM"

Remove-AzVMDataDisk -VM $VirtualMachine -Name "myDisk"
Update-AzVM -ResourceGroupName "myResourceGroup" -VM $VirtualMachine
El disco permanece en el almacenamiento pero ya no está acoplado a una máquina virtual.
Desconexión de un disco de datos mediante el portal

2. Seleccione la máquina virtual que tiene el disco de datos que quiere desconectar y haga clic en Detener para
desasignar la máquina virtual.
3. En el panel de la máquina virtual, seleccione Discos.
4. En la parte superior del panel Discos, seleccione Editar.
5. En el panel Discos, en el extremo derecho del disco de datos que quiere desasociar, haga clic en el botón de
desasociación.
6. Una vez que haya quitado el disco, haga clic en Guardar, en la parte superior del panel.
7. En el panel de la máquina virtual, haga clic en Información general y, luego, en el botón Iniciar de la parte
superior del panel para reiniciar la máquina virtual.
El disco permanece en el almacenamiento pero ya no está acoplado a una máquina virtual.
Pasos siguientes
Si desea reutilizar el disco de datos, basta con que lo conecte a otra máquina virtual
Uso de discos administrados en plantillas de Azure
Resource Manager
En este documento se describen las diferencias entre discos administrados y discos no administrados cuando se
usan plantillas de Azure Resource Manager para aprovisionar máquinas virtuales. Los ejemplos le ayudarán a
actualizar las plantillas existentes que usan discos no administrados a discos administrados. Como referencia,
usamos la plantilla 101-vm-simple-windows como guía. Puede ver la plantilla usando tanto discos administrados
como una versión usando discos no administrados si desea compararlas directamente.
Formato de plantilla de discos no administrados

Para comenzar, veamos cómo se implementan los discos no administrados. Cuando se crean discos no
administrados, se necesita una cuenta de almacenamiento para contener los archivos VHD. Puede crear una cuenta
de almacenamiento o usar una ya existente. En este artículo aprenderá a crear una cuenta de almacenamiento.
Cree un recurso de cuenta de almacenamiento en el bloque de recursos, como se muestra a continuación.
{
"apiVersion": "2018-07-01",
"name": "[variables('storageAccountName')]",
"sku": {
},
"kind": "Storage",
"properties": {}
}
Dentro del objeto de máquina virtual, agregue una dependencia de la cuenta de almacenamiento para garantizar
que se cree antes que la máquina virtual. En la sección storageProfile , se especifica el URI completo de la
ubicación de VHD, que hace referencia a la cuenta de almacenamiento y se necesita para el disco de OS y cualquier
disco de datos.
{
"apiVersion": "2018-10-01",
"dependsOn": [
],
"properties": {
"hardwareProfile": {...},
"osProfile": {...},
"storageProfile": {
"imageReference": {
"version": "latest"
},
"osDisk": {
"name": "osdisk",
"vhd": {
"uri": "[concat(reference(resourceId('Microsoft.Storage/storageAccounts/',
variables('storageAccountName'))).primaryEndpoints.blob, 'vhds/osdisk.vhd')]"
},
},
"dataDisks": [
{
"name": "datadisk1",
"diskSizeGB": 1023,
"lun": 0,
"vhd": {
"uri": "[concat(reference(resourceId('Microsoft.Storage/storageAccounts/',
variables('storageAccountName'))).primaryEndpoints.blob, 'vhds/datadisk1.vhd')]"
},
}
]
},
"networkProfile": {...},
"diagnosticsProfile": {...}
}
}
Formato de plantilla de discos administrados

Con Azure Managed Disks, el disco se convierte en un recurso de nivel superior y ya no es necesario que el usuario
cree una cuenta de almacenamiento. Los discos de Managed Disks se publicaron primero en la versión de API
2016-04-30-preview ; están disponibles en todas las versiones posteriores de API y, ahora, son el tipo de disco
predeterminado. En las secciones siguientes se describe la configuración predeterminada y se detalla cómo
personalizar aún más los discos.
NOTE
Se recomienda usar una versión de API posterior a 2016-04-30-preview , ya que se produjeron cambios importantes entre
2016-04-30-preview y 2017-03-30 .
Configuración predeterminada de discos administrados

Para crear una máquina virtual con discos administrados, ya no es necesario crear el recurso de cuenta de
almacenamiento y es posible actualizar el recurso de máquina virtual como se indica a continuación. Observe
específicamente que apiVersion refleja 2017-03-30 y ni osDisk ni dataDisks hacen referencia ya a un URI
específico para el VHD. Cuando se realiza la implementación sin especificar propiedades adicionales, el disco usará
un tipo de almacenamiento acorde con el tamaño de la máquina virtual. Por ejemplo, si usa un tamaño de máquina
virtual compatible con Premium (tamaños con "s" en el nombre, como Standard_D2s_v3) el sistema usará un
almacenamiento Premium_LRS. Use la configuración de la SKU del disco para especificar un tipo de
almacenamiento. Si no se especifica ningún nombre, toma el formato de <VMName>_OsDisk_1_<randomstring> para el
disco de SO y <VMName>_disk<#>_<randomstring> para cada disco de datos. De manera predeterminada, Azure Disk
Encryption está deshabilitado; el almacenamiento en caché es Lectura/escritura en el caso del disco de SO y
Ninguno para los discos de datos. En el ejemplo siguiente, puede observar que todavía existe una dependencia de
cuenta de almacenamiento, pero es solo para el almacenamiento de diagnósticos y no es necesaria para
almacenamiento en disco.
{
"apiVersion": "2018-10-01",
"dependsOn": [
],
"properties": {
"osProfile": {...},
"storageProfile": {
"imageReference": {
"version": "latest"
},
"osDisk": {
},
"dataDisks": [
{
"diskSizeGB": 1023,
"lun": 0,
}
]
},
}
}
Uso de un recurso de disco administrado de nivel superior

Como alternativa para especificar la configuración de disco en el objeto de máquina virtual, puede crear un recurso
de disco de nivel superior y adjuntarlo como parte de la creación de la máquina virtual. Por ejemplo, puede crear
un recurso de disco de la manera siguiente para usarlo como un disco de datos.
{
"type": "Microsoft.Compute/disks",
"apiVersion": "2018-06-01",
"name": "[concat(variables('vmName'),'-datadisk1')]",
"sku": {
},
"properties": {
"creationData": {
},
"diskSizeGB": 1023
}
}
Dentro del objeto de máquina virtual, puede hacer referencia a este objeto de disco para adjuntarlo. Especificar el
identificador de recurso del disco administrado que creamos en la propiedad managedDisk permite adjuntar el
disco cuando se crea la máquina virtual. El valor de la propiedad apiVersion del recurso de máquina virtual está
establecido en 2017-03-30 . Se agrega una dependencia del recurso de disco para garantizar que se cree
correctamente antes de la creación de la máquina virtual.
{
"apiVersion": "2018-10-01",
"dependsOn": [
"[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]",
"[resourceId('Microsoft.Compute/disks/', concat(variables('vmName'),'-datadisk1'))]"
],
"properties": {
"osProfile": {...},
"storageProfile": {
"imageReference": {
"version": "latest"
},
"osDisk": {
},
"dataDisks": [
{
"lun": 0,
"name": "[concat(variables('vmName'),'-datadisk1')]",
"createOption": "attach",
"managedDisk": {
"id": "[resourceId('Microsoft.Compute/disks/', concat(variables('vmName'),'-
datadisk1'))]"
}
}
]
},
}
}
Creación de conjuntos de disponibilidad administrados con máquinas virtuales con discos administrados
Para crear conjuntos de disponibilidad administrados con máquinas virtuales con discos administrados, agregue el
objeto sku al recurso de conjunto de disponibilidad y establezca la propiedad name en Aligned . Esta propiedad
garantiza que los discos de cada máquina virtual estén suficientemente aislados entre sí para evitar puntos únicos
de error. Tenga en cuenta también que el valor de la propiedad apiVersion del recurso del conjunto de
disponibilidad está establecido en 2018-10-01 .
{
"type": "Microsoft.Compute/availabilitySets",
"apiVersion": "2018-10-01",
"name": "[variables('avSetName')]",
"properties": {
"PlatformUpdateDomainCount": 3,
"PlatformFaultDomainCount": 2
},
"sku": {
"name": "Aligned"
}
}
Discos SSD estándar

A continuación se muestran los parámetros necesarios de la plantilla de Resource Manager para crear discos SSD
estándar:
La apiVersion para Microsoft.Compute se debe establecer en 2018-04-01 (o posterior)
Especifique managedDisk.storageAccountType como StandardSSD_LRS
El siguiente ejemplo muestra la sección properties.storageProfile.osDisk de una máquina virtual que usa un disco
SSD estándar:
"osDisk": {
"name": "myOsDisk",
"createOption": "FromImage",
"managedDisk": {
"storageAccountType": "StandardSSD_LRS"
}
}
Para obtener un ejemplo de plantilla completa de cómo crear un disco SSD estándar con una plantilla, consulte
Create a VM from a Windows Image with Standard SSD Data Disks (Creación de una máquina virtual a partir de
una imagen de Windows con discos de datos SSD estándar).
Personalizaciones y escenarios adicionales
Para información completa sobre las especificaciones de API de REST, revise la documentación sobre cómo crear
una API de REST de disco administrado. Encontrará escenarios adicionales, además de los valores
predeterminados y aceptables que se pueden enviar a la API a través de implementaciones de plantilla.
Pasos siguientes
Para conocer las plantillas completas que usan discos administrados, viste los vínculos siguientes al repositorio
de inicio rápido de Azure.
Máquina virtual Windows con disco administrado
Máquina virtual Linux con disco administrado
Visite el documento Introducción a Azure Managed Disks para más información sobre los discos administrados.
Revise la documentación de referencia de plantilla de los recursos de máquina virtual en el documento de
referencia de plantilla Microsoft.Compute/virtualMachines.
Revise la documentación de referencia de plantilla de los recursos de disco en el documento de referencia de
plantilla Microsoft.Compute/disks.
Para más información acerca del uso de discos administrados en Azure Virtual Machine Scale Sets, consulte el
documento Uso de discos de datos con conjuntos de escalado.
Carga de un disco duro virtual en Azure mediante
Azure PowerShell
En este artículo se explica cómo cargar un disco duro virtual de una máquina local en un disco administrado de
Azure. Antes había que seguir un proceso más complicado, que incluía el almacenamiento provisional de los datos
en una cuenta de almacenamiento y la administración de dicha cuenta. Ya no es preciso administrar una cuenta de
almacenamiento ni almacenar en ella datos temporalmente para cargar un disco duro virtual. En su lugar, cree un
disco administrado vacío y cargue un disco duro virtual directamente en él. Así se simplifica la carga de máquinas
virtuales locales en Azure y permite cargar un disco duro virtual hasta 32 TiB directamente en un disco
administrado de gran tamaño.
Si va a proporcionar una solución de copia de seguridad para las máquinas virtuales de IaaS en Azure, se
recomienda usar la carga directa para restaurar las copias de seguridad de clientes en discos administrados. Si va
a cargar un disco duro virtual desde una máquina externa a Azure, las velocidades dependerán del ancho de
banda local. Si usa una máquina virtual de Azure, el ancho de banda será el mismo que el de los discos duros
estándar.
Actualmente, la carga directa es compatible con los HDD estándar, la unidad de estado sólido estándar y los discos
administrados SSD prémium. Aún no es compatible con el almacenamiento en discos Ultra.
Requisitos previos
Descargue la versión más reciente de AzCopy, v10.
Instale el módulo de Azure PowerShell.
Si tiene previsto cargar un disco duro virtual desde on-pem: Un disco duro virtual que se ha preparado para
Azure, almacenado localmente.
O bien, un disco administrado en Azure, si desea realizar una acción de copia.
Creación de un disco administrado vacío

Para cargar un disco duro virtual en Azure, deberá crear un disco administrado vacío que esté configurado para
este proceso de carga. Antes de crearlo, hay información adicional que debe saber acerca de estos discos.
Este tipo de disco administrado tiene dos estados únicos:
ReadToUpload, que significa que el disco está listo para recibir una carga pero no se ha generado ninguna
firma de acceso seguro.
ActiveUpload, que significa que el disco está listo para recibir una carga y se ha generado la SAS.
Mientras esté en cualquiera de estos estados, el disco administrado se facturará al precio de un HDD estándar,
independientemente del tipo real de disco. Por ejemplo, un P10 se facturará como un S10. Esto sucederá hasta
que se llame a revoke-access en el disco administrado, que es necesario para conectar el disco a una máquina
virtual.
Antes de crear un HDD estándar vacío para cargarlo, necesitará el tamaño de archivo en bytes del disco duro
virtual que desea cargar. El código de ejemplo lo recibirá, pero para hacerlo usted puede usar:
$vhdSizeBytes = (Get-Item "<fullFilePathHere>").length . Este valor se usa al especificar el parámetro -
UploadSizeInBytes.
Ahora, en el shell local, cree un HDD estándar vacío para la carga mediante la especificación del valor Upload en
el parámetro -CreateOption, así como el parámetro -UploadSizeInBytes del cmdlet New -AzDiskConfig.
Después, llame a New -AzDisk para crear el disco:
$vhdSizeBytes = (Get-Item "<fullFilePathHere>").length
$diskconfig = New-AzDiskConfig -SkuName 'Standard_LRS' -OsType 'Windows' -UploadSizeInBytes $vhdSizeBytes -

Location 'West US' -CreateOption 'Upload'
New-AzDisk -ResourceGroupName 'myResourceGroup' -DiskName 'myDiskName' -Disk $diskconfig
Si desea cargar un disco SSD prémium o un disco SSD estándar, reemplace Standard_LRS por Premium_LRS o
StandardSSD_LRS. Aún no se admite el almacenamiento en disco Ultra.
Ahora ha creado un disco administrado vacío que está configurado para el proceso de carga. Para cargar un disco
duro virtual en ese disco, necesitará una SAS grabable, con el fin de que pueda hacer referencia a ella como el
destino de la carga.
Para generar una SAS grabable de un disco administrado vacío, use el siguiente comando:
$diskSas = Grant-AzDiskAccess -ResourceGroupName 'myResouceGroup' -DiskName 'myDiskName' -DurationInSecond

86400 -Access 'Write'
$disk = Get-AzDisk -ResourceGroupName 'myResourceGroup' -DiskName 'myDiskName'
Carga de disco duro virtual

Ahora que tiene una SAS para el disco administrado vacío, puede usarla para establecer el disco administrado
como destino del comando de carga.
Use AzCopy V10 para cargar el archivo VHD local en un disco administrado, para lo que se especifica el
identificador URI de SAS que ha generado.
Esta carga tiene el mismo rendimiento que el HDD estándar equivalente. Por ejemplo, si tiene un tamaño que
equivale a S4, tendrá un rendimiento de hasta 60 MiB/s. Pero si tiene un tamaño que equivale a S70, tendrá un
rendimiento de hasta 500 MiB/s.
AzCopy.exe copy "c:\somewhere\mydisk.vhd"$diskSas.AccessSAS --blob-type PageBlob
Si la SAS expira durante la carga y aún no ha llamado a revoke-access , puede obtener una nueva SAS para
continuar con la carga mediante grant-access .
Cuando finalice la carga y ya no necesite escribir más datos en el disco, revoque la SAS. Al revocar la SAS,
cambiará el estado del disco administrado y podrá conectar el disco a una máquina virtual.
Revoke-AzDiskAccess -ResourceGroupName 'myResourceGroup' -DiskName 'myDiskName'

La carga directa también simplifica el proceso de copia de un disco administrado. Puede copiar dentro de la
misma región o entre regiones (a otra región).
El script siguiente lo hará automáticamente, el proceso es similar a los pasos descritos anteriormente, con algunas
diferencias porque está trabajando con un disco existente.
IMPORTANT
Debe agregar un desplazamiento de 512 cuando proporcione el tamaño de disco en bytes de un disco administrado de
Azure. Esto se debe a que Azure omite el pie de página al devolver el tamaño del disco. Si no lo hace, se producirá un error
en la copia. El siguiente script ya lo hace automáticamente.
Reemplace los <sourceResourceGroupHere> , <sourceDiskNameHere> , ,

<targetDiskNameHere>
(
<targetResourceGroupHere> , <yourOSTypeHere> y <yourTargetLocationHere> un ejemplo de un valor de ubicación
sería uswest2) con sus valores y, a continuación, ejecute el siguiente script para copiar un disco administrado.
$sourceRG = <sourceResourceGroupHere>
$sourceDiskName = <sourceDiskNameHere>
$targetDiskName = <targetDiskNameHere>
$targetRG = <targetResourceGroupHere>
$targetLocate = <yourTargetLocationHere>
#Expected value for OS is either "Windows" or "Linux"
$targetOS = <yourOSTypeHere>
$sourceDisk = Get-AzDisk -ResourceGroupName $sourceRG -DiskName $sourceDiskName
# Adding the sizeInBytes with the 512 offset, and the -Upload flag
$targetDiskconfig = New-AzDiskConfig -SkuName 'Standard_LRS' -osType $targetOS -UploadSizeInBytes
$($sourceDisk.DiskSizeBytes+512) -Location $targetLocate -CreateOption 'Upload'
$targetDisk = New-AzDisk -ResourceGroupName $targetRG -DiskName $targetDiskName -Disk $targetDiskconfig
$sourceDiskSas = Grant-AzDiskAccess -ResourceGroupName $sourceRG -DiskName $sourceDiskName -DurationInSecond

86400 -Access 'Read'
$targetDiskSas = Grant-AzDiskAccess -ResourceGroupName $targetRG -DiskName $targetDiskName -DurationInSecond

86400 -Access 'Write'
azcopy copy $sourceDiskSas.AccessSAS $targetDiskSas.AccessSAS --blob-type PageBlob
Revoke-AzDiskAccess -ResourceGroupName $sourceRG -DiskName $sourceDiskName
Revoke-AzDiskAccess -ResourceGroupName $targetRG -DiskName $targetDiskName
Pasos siguientes
Ahora que ha cargado correctamente un disco duro virtual en un disco administrado, puede conectar el disco a
una máquina virtual y empezar a usarlo.
Para aprender a conectar un disco de datos a una máquina virtual, consulte nuestro artículo al respecto: Conexión
de un disco a una VM Windows con PowerShell. Para usar el disco como disco del sistema operativo, consulte
Creación de una máquina virtual Windows desde un disco especializado.
Cómo ampliar la unidad de sistema operativo de una
máquina virtual
Cuando se crea una nueva máquina virtual (VM ) en un grupo de recursos mediante la implementación de una
imagen de Azure Marketplace, la unidad del sistema operativo predeterminada suele tener 127 GB (algunas
imágenes son más pequeñas de manera predeterminada). Aunque es posible agregar discos de datos a la
máquina virtual (la cantidad depende de la SKU que haya elegido) y, además, se recomienda instalar aplicaciones
y cargas de trabajo intensivas de CPU en estos discos de anexo, a menudo los clientes necesitan expandir la
unidad del sistema operativo para admitir determinados escenarios, como los siguientes:
Compatibilidad con aplicaciones heredadas que instalan componentes en la unidad del sistema operativo.
Migración de una máquina virtual o un equipo físico desde local con una unidad del sistema operativo más
grande.
IMPORTANT
Para cambiar el tamaño del disco del sistema operativo de una máquina virtual de Azure requiere que se desasigne la
máquina virtual.
Después de expandir los discos, necesita expandir el volumen dentro del sistema operativo para aprovechar el disco más
grande.
Cambio de tamaño de un disco administrado

Abra la ventana de Powershell o Powershell ISE en el modo administrativo y siga estos pasos:
1. Inicie sesión en su cuenta de Microsoft Azure en el modo de administración de recursos y seleccione su
suscripción de la siguiente manera:
Connect-AzAccount
Select-AzSubscription –SubscriptionName 'my-subscription-name'
2. Configure el nombre de grupo de recursos y el nombre de la máquina virtual de la siguiente forma:
$rgName = 'my-resource-group-name'
$vmName = 'my-vm-name'
3. Obtenga una referencia a la máquina virtual de la siguiente manera:
$vm = Get-AzVM -ResourceGroupName $rgName -Name $vmName
4. Detenga la máquina virtual antes de cambiar el tamaño del disco de la siguiente forma:
Stop-AzVM -ResourceGroupName $rgName -Name $vmName
5. Obtenga una referencia al disco del sistema operativo administrado. Configure el tamaño del disco del
sistema operativo en el valor deseado y actualice el disco de la siguiente manera:
$disk= Get-AzDisk -ResourceGroupName $rgName -DiskName $vm.StorageProfile.OsDisk.Name
$disk.DiskSizeGB = 1023
Update-AzDisk -ResourceGroupName $rgName -Disk $disk -DiskName $disk.Name
WARNING
El nuevo tamaño debe ser mayor que el tamaño de disco existente. El máximo permitido es 2048 GB para discos del
sistema operativo. (el blob de VHD se puede expandir más, pero el sistema operativo solo podrá trabajar con los
primeros 2048 GB).
6. La actualización de la máquina virtual puede tardar unos segundos. Una vez que el comando acabe de
ejecutarse, reinicie la máquina virtual de la siguiente forma:
Start-AzVM -ResourceGroupName $rgName -Name $vmName
Eso es todo. Ahora RDP en la máquina virtual, abra Administración de equipos (o Administración de discos) y
expanda la unidad utilizando el espacio recién asignado.
Cambio de tamaño de un disco no administrado

Abra la ventana de Powershell o Powershell ISE en el modo administrativo y siga estos pasos:
1. Inicie sesión en su cuenta de Microsoft Azure en el modo de administración de recursos y seleccione su
suscripción de la siguiente manera:
Connect-AzAccount
Select-AzSubscription –SubscriptionName 'my-subscription-name'
2. Configure el nombre de grupo de recursos y el nombre de la máquina virtual de la siguiente forma:
3. Obtenga una referencia a la máquina virtual de la siguiente manera:
4. Detenga la máquina virtual antes de cambiar el tamaño del disco de la siguiente forma:
5. Configure el tamaño del disco del sistema operativo no administrado en el valor deseado y actualice la
máquina virtual de la siguiente manera:
$vm.StorageProfile.OSDisk.DiskSizeGB = 1023
WARNING
El nuevo tamaño debe ser mayor que el tamaño de disco existente. El máximo permitido es 2048 GB para discos del
sistema operativo. (el blob de VHD se puede expandir más, pero el sistema operativo solo podrá trabajar con los
primeros 2048 GB).
6. La actualización de la máquina virtual puede tardar unos segundos. Una vez que el comando acabe de
ejecutarse, reinicie la máquina virtual de la siguiente forma:
Scripts para el disco del sistema operativo

A continuación se muestra el script completo para su referencia tanto para discos administrados como no
administrados:
Discos administrados
Connect-AzAccount
Select-AzSubscription -SubscriptionName 'my-subscription-name'
$disk= Get-AzDisk -ResourceGroupName $rgName -DiskName $vm.StorageProfile.OsDisk.Name
Update-AzDisk -ResourceGroupName $rgName -Disk $disk -DiskName $disk.Name
Discos no administrados
Connect-AzAccount
Select-AzSubscription -SubscriptionName 'my-subscription-name'
$vm.StorageProfile.OSDisk.DiskSizeGB = 1023
Cambio de tamaño de los discos de datos

Este artículo se centra principalmente en expandir el disco del sistema operativo de la máquina virtual, pero el
script también puede utilizarse para expandir los discos de datos asociados a la máquina virtual. Por ejemplo, para
expandir el primer disco de datos conectado a la máquina virtual, reemplace el objeto OSDisk de StorageProfile
por la matriz DataDisks y utilice un índice numérico para obtener una referencia al primer disco de datos
conectado, como se muestra a continuación:
Disco administrado
$disk= Get-AzDisk -ResourceGroupName $rgName -DiskName $vm.StorageProfile.DataDisks[0].Name

Disco no administrado
$vm.StorageProfile.DataDisks[0].DiskSizeGB = 1023
Del mismo modo, puede hacer referencia a otros discos de datos conectados a la máquina virtual, ya sea mediante
un índice, como se muestra arriba, o con la propiedad del disco Name:
Disco administrado
(Get-AzDisk -ResourceGroupName $rgName -DiskName ($vm.StorageProfile.DataDisks | Where ({$_.Name -eq 'my-

second-data-disk'})).Name).DiskSizeGB = 1023
Disco no administrado
($vm.StorageProfile.DataDisks | Where ({$_.Name -eq 'my-second-data-disk'}).DiskSizeGB = 1023
Expansión del volumen en el sistema operativo

Cuando haya expandido el disco para la máquina virtual, deberá entrar en el sistema operativo y expandir el
volumen para abarcar el nuevo espacio. Existen varios métodos para expandir una partición. En esta sección se
trata la conexión de la máquina virtual mediante una conexión RDP para expandir la partición mediante DiskPart.
1. Abra una conexión RDP a la máquina virtual.
2. Abra un símbolo del sistema y escriba diskpart.
3. En el símbolo del sistema DISKPART, escriba list volume . Tome nota del volumen que desea extender.
4. En el símbolo del sistema DISKPART, escriba select volume <volumenumber> . Este comando selecciona el
volumen númeroDeVolumen que desea extender en el espacio vacío contiguo del mismo disco.
5. En el símbolo del sistema DISKPART, escriba extend [size=<size>] . Este comando extiende el volumen
seleccionado por tamaño en megabytes (MB ).
Pasos siguientes
También puede asociar discos mediante Azure Portal.
Uso del Explorador de Azure Storage para
administrar discos administrados de Azure
Explorador de Storage 1.10.0 permite a los usuarios cargar, descargar y copiar discos administrados, así como crear
instantáneas. Debido a estas capacidades adicionales, puede usar Explorador de Storage para migrar datos desde
una ubicación local a Azure y migrar datos entre regiones de Azure.
Requisitos previos
Para completar este artículo, necesitará lo siguiente:
Una suscripción de Azure
Uno o varios discos administrados de Azure
La versión más reciente de Explorador de Azure Storage
Conexión a una suscripción de Azure

Si el Explorador de Storage no está conectado a Azure, no podrá usarlo para administrar los recursos. En esta
sección se explica cómo conectarse a su cuenta de Azure para que pueda administrar los recursos mediante
Explorador de Storage.
1. Inicie Explorador de Azure Storage y haga clic en el icono de complemento de la izquierda.
2. Seleccione Agregar una cuenta de Azure y haga clic en Siguiente.
3. En el cuadro de diálogo Iniciar sesión en Azure, escriba sus credenciales de Azure.
4. Seleccione la suscripción en la lista y luego haga clic en Aplicar.
Cargar un disco administrado desde un VHD local
1. En el panel izquierdo, expanda Discos y seleccione el grupo de recursos en el que desea cargar el disco.
2. Seleccione Cargar.
3. En Cargar VHD especifique el VHD de origen, el nombre del disco, el tipo de sistema operativo, la región a
la que desea cargar el disco y el tipo de cuenta. En algunas regiones, se admiten zonas de disponibilidad,
para las cuales puede seleccionar la zona deseada.
4. Seleccione Crear para empezar a cargar el disco.
5. El estado de la carga ahora se mostrará en Actividades.
6. Si la carga ha finalizado y no ve el disco en el panel derecho, seleccione Actualizar.
Descargar un disco administrado

En los pasos siguientes se explica cómo descargar un disco administrado en un VHD local. Para que un disco se
pueda descargar, su estado debe ser Sin conectar. No puede descargar un disco con el estado Conectado.
1. En el panel izquierdo, si aún no está expandido, expanda Discos y seleccione el grupo de recursos desde el
que desea descargar el disco.
2. En el panel derecho, seleccione el disco que desea descargar.
3. Seleccione Descargar y elija dónde desea guardar el disco.
4. Seleccione Guardar y el disco comenzará a descargarse. El estado de la descarga se mostrará en

Actividades.

Con Explorador de Storage, puede copiar un disco superpuesto dentro o entre regiones. Para copiar un disco:
1. En la lista desplegable Discos de la izquierda, seleccione el grupo de recursos que contiene el disco que
desea copiar.
2. En el panel derecho, elija el disco que desea copiar y seleccione Copiar.
3. En el panel izquierdo, seleccione el grupo de recursos en el que desea pegar el disco.

4. Seleccione Pegar en el panel derecho.
5. En el cuadro de diálogo Pegar un disco, rellene los valores. También puede especificar una zona de
disponibilidad en las regiones admitidas.
6. Seleccione Pegar y el disco comenzará a copiarse. El estado se muestra en Actividades.
Crear una instantánea

1. En la lista desplegable Discos de la izquierda, seleccione el grupo de recursos que contiene el disco del que
desea crear una instantánea.
2. A la derecha, seleccione el disco del que desea crear una instantánea y seleccione Crear instantánea.
3. En Crear instantánea, especifique el nombre de la instantánea, así como el grupo de recursos en el que
desea crearla. Seleccione Crear.
4. Una vez creada la instantánea, puede seleccionar Abrir en el portal en Actividades para ver la instantánea
en el Azure Portal.
Pasos siguientes
Aprenda a crear una máquina virtual a partir de un disco duro virtual mediante Azure Portal .
Aprenda a conectar un disco de datos administrado a una máquina virtual Windows con Azure Portal.
Crear una instantánea
Una instantánea es una copia completa de solo lectura de un disco duro virtual (VHD ). Tome una instantánea de
un disco duro virtual de datos o del sistema operativo para realizar una copia de seguridad o para solucionar
problemas de la máquina virtual.
Si va a usar la instantánea para crear una máquina virtual, se recomienda un cierre limpio de la máquina virtual
antes de tomar una instantánea para así limpiar cualquier proceso que esté en curso.
Uso de Azure Portal

2. En el menú izquierdo, seleccione Crear un recurso y, a continuación, busque y seleccione instantánea.
3. En la ventana Instantánea, seleccione Crear. Aparece la ventana Crear instantánea.
4. Escriba un nombre para la instantánea.
5. Seleccione un Grupo de recursos existente o escriba el nombre de uno nuevo.
6. Seleccione una ubicación del centro de datos de Azure.
7. Como disco de origen, seleccione el disco administrado para la instantánea.
8. Seleccione el tipo de cuenta que se usará para almacenar la instantánea. Use Standard_HDD, a menos que
necesite que la instantánea se almacene en un disco de alto rendimiento.
9. Seleccione Crear.
Uso de PowerShell
Los pasos siguientes muestran cómo copiar el disco duro virtual, crear la configuración de la instantánea y crear
una instantánea del disco con el cmdlet New -AzSnapshot.
1. Configure algunos parámetros:
$location = 'eastus'
$vmName = 'myVM'
$snapshotName = 'mySnapshot'
2. Obtenga la máquina virtual:
$vm = get-azvm `
-Name $vmName
3. Cree la configuración de la instantánea. En este ejemplo, es la instantánea del disco del sistema operativo:
$snapshot = New-AzSnapshotConfig
-SourceUri $vm.StorageProfile.OsDisk.ManagedDisk.Id
-Location $location
-CreateOption copy
NOTE
Si desea almacenar la instantánea en un almacenamiento resistente a zonas, debe crearla en una región que
admita zonas de disponibilidad e incluir el parámetro -SkuName Standard_ZRS .
4. Tome la instantánea:
New-AzSnapshot
-Snapshot $snapshot
-SnapshotName $snapshotName
Pasos siguientes
Cree una máquina virtual a partir de una instantánea; para ello, cree primero un disco administrado con la
instantánea y conéctelo como disco del sistema operativo. Para más información, consulte el ejemplo de
Creación de una máquina virtual a partir de una instantánea con PowerShell .
Creación de una instantánea incremental (versión
preliminar) para discos administrados
Las instantáneas incrementales (versión preliminar) son copias de seguridad en un momento dado de los discos
administrados que, cuando se realizan, solo constan de todos los cambios desde la última instantánea. Al intentar
descargar o usar una instantánea incremental, se utiliza el VHD completo. Esta nueva funcionalidad para las
instantáneas de discos administrados puede permitir que sean más rentables, ya que no es necesario almacenar
todo el disco con cada instantánea individual a menos que decida hacerlo expresamente. Al igual que las
instantáneas normales, las instantáneas incrementales se pueden usar para crear un disco administrado completo o
para realizar una instantánea normal.
Hay algunas diferencias entre una instantánea incremental y una instantánea normal. Las instantáneas
incrementales usan siempre el almacenamiento de discos HDD estándar, independientemente del tipo de
almacenamiento del disco, mientras que las instantáneas periódicas pueden usar discos SSD Premium. Si usa
instantáneas periódicas en Premium Storage para escalar verticalmente implementaciones de máquinas virtuales,
le recomendamos que use imágenes personalizadas en el almacenamiento estándar de Shared Image Gallery. Le
ayudará a lograr una escala más masiva con un costo más bajo. Además, las instantáneas incrementales pueden
ofrecer mejor confiabilidad con el almacenamiento con redundancia de zona. Si el almacenamiento con
redundancia de zona está disponible en la región seleccionada, una instantánea incremental lo usará
automáticamente. Si el almacenamiento con redundancia de zona no está disponible en la región, la instantánea
tendrá como valor predeterminado el almacenamiento con redundancia local. Puede invalidar este
comportamiento y seleccionar uno manualmente, pero no es recomendable.
Las instantáneas incrementales también ofrecen una funcionalidad diferencial, que está disponible de forma única
para los discos administrados. Permiten obtener los cambios entre dos instantáneas incrementales de los mismos
discos administrados hasta el nivel de bloque. Puede usar esta funcionalidad para reducir la superficie de los datos
al copiar instantáneas entre regiones.
Si aún no se ha suscrito a la versión preliminar y le gustaría empezar a usar instantáneas incrementales, envíenos
un correo electrónico a AzureDisks@microsoft.com para acceder a la versión preliminar pública.
Restricciones
Las instantáneas incrementales solo están disponibles actualmente en las regiones Centro-oeste de EE. UU. y
Norte de Europa.
Actualmente, las instantáneas incrementales no se pueden crear después de cambiar el tamaño de un disco.
Las instantáneas incrementales no se pueden mover entre suscripciones.
En este momento, solo se pueden generar URI de SAS de hasta cinco instantáneas de una determinada familia
de instantáneas en un momento dado.
No se puede crear una instantánea incremental para un disco determinado fuera de la suscripción de ese disco.
Se pueden crear hasta siete instantáneas incrementales por disco cada cinco minutos.
Se pueden crear un total de 200 instantáneas incrementales para un único disco.
PowerShell
Puede usar Azure PowerShell para crear y administrar recursos compartidos de archivos. Necesitará la versión
más reciente de Azure PowerShell y el siguiente comando la instalará o actualizará la instalación existente a la más
reciente:
Install-Module -Name Az -AllowClobber -Scope CurrentUser
Una vez instalada, inicie sesión en PowerShell con az login .

Para crear una instantánea incremental con Azure PowerShell, establezca la configuración con New -
AzSnapShotConfig con el parámetro -Incremental y, después, páselo como una variable a New -AzSnapshot con
el parámetro -Snapshot .
Reemplace <yourDiskNameHere> , <yourResourceGroupNameHere> y <yourDesiredSnapShotNameHere> por sus valores; a
continuación, puede usar el script siguiente para crear una instantánea incremental:
# Get the disk that you need to backup by creating an incremental snapshot
$yourDisk = Get-AzDisk -DiskName <yourDiskNameHere> -ResourceGroupName <yourResourceGroupNameHere>
# Create an incremental snapshot by setting the SourceUri property with the value of the Id property of the
disk
$snapshotConfig=New-AzSnapshotConfig -SourceUri $yourDisk.Id -Location $yourDisk.Location -CreateOption Copy -
Incremental
New-AzSnapshot -ResourceGroupName <yourResourceGroupNameHere> -SnapshotName <yourDesiredSnapshotNameHere> -
Snapshot $snapshotConfig
Puede identificar las instantáneas incrementales desde el mismo disco con las propiedades SourceResourceId y
SourceUniqueId de las instantáneas. SourceResourceId es el identificador de recursos de Azure Resource Manager
del disco principal. SourceUniqueId es el valor heredado de la propiedad UniqueId del disco. Si fuera a eliminar un
disco y después creara otro con el mismo nombre, el valor de la propiedad UniqueId cambiaría.
Puede usar SourceResourceId y SourceUniqueId para crear una lista de todas las instantáneas asociadas a un disco
determinado. Reemplace <yourResourceGroupNameHere> por su valor y, a continuación, puede usar el ejemplo
siguiente para enumerar las instantáneas incrementales existentes:
$snapshots = Get-AzSnapshot -ResourceGroupName <yourResourceGroupNameHere>
$incrementalSnapshots = New-Object System.Collections.ArrayList

foreach ($snapshot in $snapshots)
{
if($snapshot.Incremental -and $snapshot.CreationData.SourceResourceId -eq $yourDisk.Id -and

$snapshot.CreationData.SourceUniqueId -eq $yourDisk.UniqueId){
$incrementalSnapshots.Add($snapshot)
}
}
$incrementalSnapshots
CLI
Puede crear una instantánea incremental con la CLI de Azure, para lo que necesitará la versión más reciente. El
siguiente comando la instalará o actualizará la instalación existente a la más reciente:
Invoke-WebRequest -Uri https://aka.ms/installazurecliwindows -OutFile .\AzureCLI.msi; Start-Process msiexec.exe

-Wait -ArgumentList '/I AzureCLI.msi /quiet'
Para crear una instantánea incremental, use az snapshot create con el parámetro --incremental .
En el ejemplo siguiente se crea una instantánea incremental; reemplace <yourDesiredSnapShotNameHere> ,
<yourResourceGroupNameHere> , <exampleDiskName> y <exampleLocation> por sus propios valores y, a continuación,
ejecute el ejemplo:
sourceResourceId=$(az disk show -g <yourResourceGroupNameHere> -n <exampleDiskName> --query '[id]' -o tsv)
az snapshot create -g <yourResourceGroupNameHere> \

-n <yourDesiredSnapShotNameHere> \
-l <exampleLocation> \
--source "$sourceResourceId" \
--incremental
Puede identificar las instantáneas incrementales desde el mismo disco con las propiedades SourceResourceId y
SourceUniqueId de las instantáneas. SourceResourceId es el identificador de recursos de Azure Resource Manager
del disco principal. SourceUniqueId es el valor heredado de la propiedad UniqueId del disco. Si fuera a eliminar un
disco y después creara otro con el mismo nombre, el valor de la propiedad UniqueId cambiaría.
Puede usar SourceResourceId y SourceUniqueId para crear una lista de todas las instantáneas asociadas a un disco
determinado. En el ejemplo siguiente se enumeran todas las instantáneas incrementales asociadas a un disco
determinado, pero se requiere cierta configuración.
En este ejemplo se usa jq para consultar los datos. Para ejecutar el ejemplo, debe instalar jq.
Reemplace <yourResourceGroupNameHere> y <exampleDiskName> por sus valores, y después puede usar el ejemplo
siguiente para enumerar las instantáneas incrementales existentes, siempre y cuando también haya instalado jq:
sourceUniqueId=$(az disk show -g <yourResourceGroupNameHere> -n <exampleDiskName> --query '[uniqueId]' -o tsv)
sourceResourceId=$(az disk show -g <yourResourceGroupNameHere> -n <exampleDiskName> --query '[id]' -o tsv)
az snapshot list -g <yourResourceGroupNameHere> -o json \

| jq -cr --arg SUID "$sourceUniqueId" --arg SRID "$sourceResourceId" '.[] | select(.incremental==true and
.creationData.sourceUniqueId==$SUID and .creationData.sourceResourceId==$SRID)'

También puede usar plantillas de Azure Resource Manager para crear una instantánea incremental. Deberá
asegurarse de que apiVersion esté establecido en 2019-03-01 y que la propiedad incremental también esté
establecida en true. El siguiente fragmento de código es un ejemplo de cómo crear una instantánea incremental
con las plantillas de Resource Manager:
{
"parameters": {
"diskName": {
"type": "string",
"defaultValue": "contosodisk1"
},
"diskResourceId": {
"defaultValue": "<your_managed_disk_resource_ID>",
"type": "String"
}
},
"resources": [
{
"type": "Microsoft.Compute/snapshots",
"name": "[concat( parameters('diskName'),'_snapshot1')]",
"apiVersion": "2019-03-01",
"properties": {
"creationData": {
"createOption": "Copy",
"sourceResourceId": "[parameters('diskResourceId')]"
},
"incremental": true
}
}
]
}
Pasos siguientes
Si aún no se ha suscrito a la versión preliminar y le gustaría empezar a usar instantáneas incrementales, envíenos
un correo electrónico a AzureDisks@microsoft.com para acceder a la versión preliminar pública.
Copias de seguridad de discos de máquinas virtuales
de Azure no administrados con instantáneas
incrementales
Azure Storage permite realizar instantáneas de blobs. Dichas instantáneas capturan el estado del blob en el
preciso momento en el que se realicen. En este artículo, se describe un escenario para mantener copias de
seguridad de discos de máquinas virtuales por medio de instantáneas. Podrá utilizar esta metodología cuando
opte por no usar el servicio de recuperación y copia de seguridad de Azure y quiera crear una estrategia de copias
de seguridad personalizada para los discos de sus máquinas virtuales.
Los discos de las máquinas virtuales de Azure se almacenan como blobs en páginas en Azure Storage. Como en
este artículo se describe una estrategia de copias de seguridad para discos de máquinas virtuales, cuando
hablemos de instantáneas, lo haremos en el contexto de blobs en páginas. Para obtener más información sobre las
instantáneas, consulte Creación de una instantánea a partir de un blob.
¿Qué es una instantánea?

Una instantánea de blob es una versión de solo lectura de un blob que se ha capturado en un momento dado. Una
vez se crea la instantánea, puede leerla, copiarla o eliminarla, pero no modificarla. Las instantáneas le ofrecen una
oportunidad de realizar una copia de seguridad de un blob en el momento en que éste aparezca. Hasta la versión
2015-04-05 de REST podía copiar instantáneas completas. Con la versión 2015-07-08 de REST y posteriores,
también puede copiar instantáneas incrementales.
Copia de instantáneas completas

Es posible copiar las instantáneas en otra cuenta de almacenamiento como un blob para guardar copias de
seguridad del blob de base. También puede sobrescribir el blob de base con una instantánea suya, lo que equivale
a restaurar el blob a una versión previa. Cuando una instantánea se copia de una cuenta de almacenamiento a
otra, ocupa el mismo espacio que el blob en páginas de base. Por lo tanto, la copia de instantáneas completas de
una cuenta de almacenamiento a otra es un proceso lento y consume mucho espacio en la de destino.
NOTE
Si copia el blob de base en otro destino, sus instantáneas no se copian junto con él. Igualmente, si sobrescribe un blob de
base con una copia, las instantáneas asociadas a él no se ven afectadas, sino que permanecen intactas con el nombre del
blob de base.
Copia de seguridad de discos mediante instantáneas

Como una estrategia de copias de seguridad para los discos de sus máquinas virtuales, puede realizar
instantáneas periódicas del disco o el blob en páginas y copiarlas en otra cuenta de almacenamiento mediante
herramientas como la operación Copy Blob o AzCopy. Puede copiar una instantánea en un blob en páginas de
destino con un nombre diferente. El blob en páginas de destino resultante es un blob en páginas en el que se
puede escribir y no una instantánea. Más adelante en este artículo, se describen los pasos para realizar copias de
seguridad de discos de máquinas virtuales mediante instantáneas.
Restauración de discos mediante instantáneas
Cuando llegue el momento de restaurar el disco a una versión estable capturada previamente en una de las
instantáneas de copia de seguridad, puede copiar una instantánea sobre el blob en páginas de base. Una vez que
se convierta la instantánea en el blob en páginas de base, esta se conservará, pero el origen se sobrescribe con
una copia de lectura y escritura. Más adelante en este artículo, se describen los pasos para restaurar una versión
anterior de su disco a partir de su instantánea.
Implementación de una copia una instantánea completa
Puede implementar una copia de una instantánea completa siguiendo estos pasos:
Primero, realice una instantánea del blob de base con la operación Snapshot Blob .
Después, copie la instantánea en una cuenta de almacenamiento de destino mediante Copy Blob.
Repita este proceso para mantener copias de seguridad de su blob de base.
Copia de instantáneas incrementales

La nueva característica de la API GetPageRanges ofrece un modo mucho mejor de realizar copias de seguridad de
las instantáneas de los discos o blobs en páginas. La API devuelve la lista de cambios entre el blob de base y las
instantáneas, lo que reduce la cantidad de espacio de almacenamiento utilizado en la cuenta de copia de
seguridad. La API es compatible con blobs en páginas en Premium Storage, así como en su vertiente Standard.
Gracias a esta API, puede crear soluciones de copia de seguridad más rápidas y eficaces para las máquinas
virtuales de Azure. Esta API estará disponible con la versión 2015-07-08 de REST y posteriores.
La copia de instantáneas incrementales permite realizar copiar de una cuenta de almacenamiento a otra la
diferencia entre:
Un blob de base y su instantánea, o bien
Dos instantáneas cualesquiera del blob de base
Siempre que se cumplan las condiciones siguientes:
El blob se creó a partir del 1 de enero de 2016.
El blob no se sobrescribió con PutPage o Copy Blob entre dos instantáneas.
Nota: Esta característica está disponible para blobs en páginas de Azure Premium y Standard.
Cuando se emplea una estrategia de copia de seguridad personalizada en la que se utilicen instantáneas, la copia
de estas últimas de una cuenta de almacenamiento a otra puede ser lenta y consumir mucho espacio. En lugar de
copiar toda la instantánea en una cuenta de almacenamiento de copia de seguridad, puede escribir la diferencia
entre instantáneas consecutivas en un blob en páginas de copia de seguridad. De este modo, se reduce
considerablemente el tiempo de copia y espacio necesario para almacenar las copias de seguridad.
Implementación de la copia de instantáneas incrementales
Puede implementar la copia de instantáneas incrementales siguiendo estos pasos:
Realice una instantánea del blob de base mediante Instantánea de blob.
Copie la instantánea en una cuenta de almacenamiento de copia de seguridad de destino en la misma región
de Azure (o en cualquier otra) mediante la opción Copiar blob. Este es el blob en páginas de copia de
seguridad. Realice una instantánea del blob en páginas de copia de seguridad y almacénela en la cuenta de
copia de seguridad.
Realice otra instantánea del blob de base mediante Instantánea de blob.
Obtenga la diferencia entre la primera y la segunda instantánea del blob de base mediante GetPageRanges.
Use el nuevo parámetro prevsnapshot para especificar el valor DateTime de la instantánea que quiere usar
para obtener la diferencia. Cuando este parámetro está presente, la respuesta de REST solo incorpora las
páginas que se cambiaron entre la instantánea de destino y la anterior, incluidas las borradas.
Use PutPage para aplicar estos cambios al blob en páginas de copia de seguridad.
Por último, realice una instantánea del blob en páginas de copia de seguridad y almacénela en la cuenta de
almacenamiento de copia de seguridad.
En la siguiente sección, se describirá en mayor profundidad cómo puede mantener copias de seguridad de discos
mediante la copia de instantáneas incrementales.
Escenario
En esta sección se describe un escenario en el que se utiliza una estrategia de copia de seguridad personalizada
para discos de máquinas virtuales mediante instantáneas.
Considere la posibilidad de usar una VM de Azure de serie DS con un disco P30 de almacenamiento premium
conectado. El disco P30 denominado mypremiumdisk se almacena en una cuenta de almacenamiento premium
denominada mypremiumaccount. Se usa una cuenta de almacenamiento estándar denominada
mybackupstdaccount para almacenar la copia de seguridad de mypremiumdisk. Nos gustaría mantener una
instantánea de mypremiumdisk cada 12 horas.
Para obtener más información sobre la creación de una cuenta de almacenamiento, consulte Creación de una
cuenta de almacenamiento.
Para obtener información sobre la realización de copias de seguridad de máquinas virtuales de Azure, consulte
Plan Azure VM backups(Planeación de copias de seguridad de máquinas virtuales de Azure).
Pasos para mantener copias de seguridad de un disco con instantáneas

incrementales
En los pasos que se describen a continuación se realizan instantáneas de mypremiumdisk y las copias de
seguridad se mantienen en mybackupstdaccount. La copia de seguridad es un blob en páginas estándar
denominado mybackupstdpageblob. El blob en páginas de copia de seguridad siempre refleja el mismo estado
que la última instantánea de mypremiumdisk.
1. Cree el blob en páginas de copia de seguridad para el disco de almacenamiento premium; para ello, realice una
instantánea de mypremiumdisk denominada mypremiumdisk_ss1.
2. Copie esta instantánea en mybackupstdaccount como un blob en páginas denominado mybackupstdpageblob.
3. Realice una instantánea de mybackupstdpageblob denominada mybackupstdpageblob_ss1 con Instantánea de
blob y almacénela en mybackupstdaccount.
4. En la ventana de copia de seguridad, cree otra instantánea de mypremiumdisk, por ejemplo,
mypremiumdisk_ss2, y almacénela en mypremiumaccount.
5. Obtenga los cambios incrementales entre las dos instantáneas, mypremiumdisk_ss2 y mypremiumdisk_ss1, con
GetPageRanges en mypremiumdisk_ss2 con el parámetro prevsnapshot establecido en la marca de tiempo de
mypremiumdisk_ss1. Escriba estos cambios incrementales en el blob en páginas de copia de seguridad
mybackupstdpageblob de mybackupstdaccount. Si hay intervalos eliminados en los cambios incrementales,
deben borrarse desde el blob en páginas de copia de seguridad. Use PutPage para escribir los cambios
incrementales en el blob en páginas de copia de seguridad.
6. Realice una instantánea del blob en páginas de copia de seguridad mybackupstdpageblob denominada
mybackupstdpageblob_ss2. Elimine la instantánea anterior mypremiumdisk_ss1 de la cuenta de
almacenamiento premium.
7. Repita los pasos del 4 al 6 en cada ventana de copia de seguridad. De esta forma, puede mantener copias de
seguridad de mypremiumdisk en una cuenta de almacenamiento estándar.
Pasos para restaurar un disco de las instantáneas
En los pasos siguientes se describe cómo restaurar el disco premium, mypremiumdisk, a una instantánea anterior
desde la cuenta de almacenamiento de copia de seguridad mybackupstdaccount.
1. Identifique el momento al que desea restaurar el disco premium. Supongamos que es la instantánea
mybackupstdpageblob_ss2, que se almacena en la cuenta de almacenamiento de copia de seguridad
mybackupstdaccount.
2. En mybackupstdaccount, promueva la instantánea mybackupstdpageblob_ss2 como el nuevo blob en páginas
de base de copia de seguridad mybackupstdpageblobrestored.
3. Realice una instantánea de este blob en páginas de copia de seguridad restaurado denominada
mybackupstdpageblobrestored_ss1.
4. Copie el blob en páginas restaurado mybackupstdpageblobrestored desde mybackupstdaccount en
mypremiumaccount como el nuevo disco premium mypremiumdiskrestored.
5. Realice una instantánea de mypremiumdiskrestored denominada mypremiumdiskrestored_ss1 para realizar
futuras copias de seguridad incrementales.
6. Seleccione la máquina virtual de serie DS en el disco restaurado mypremiumdiskrestored y desasocie el
mypremiumdisk anterior de la máquina virtual.
7. Inicie el proceso de copia de seguridad que se describe en la sección anterior para el disco restaurado
mypremiumdiskrestored con mybackupstdpageblobrestored como el blob en páginas de copia de seguridad.
Pasos siguientes
Obtenga información sobre cómo crear instantáneas de un blob y planear la infraestructura de copia de seguridad
de máquinas virtuales mediante los vínculos siguientes.
Crear una instantánea de un blob
Planeación de la infraestructura de copia de seguridad de máquinas virtuales
Actualizar el tipo de almacenamiento de un disco
administrado
Hay cuatro tipos de discos de Azure Managed Disks: SSD Ultra de Azure (versión preliminar), SSD Premium, SSD
estándar y HDD estándar. Puede cambiar entre los tres tipos de disco de disponibilidad general (SSD Premium,
SSD estándar y HDD estándar) según las necesidades de rendimiento. Todavía no puede cambiar de o a un SSD
Ultra; debe implementar uno nuevo.
Esta funcionalidad no se admite para discos no administrados. Sin embargo, puede convertir un disco no
administrado en un disco administrado de manera sencilla para poder cambiar entre los tipos de disco.
Requisitos previos
Debido a que la conversión requiere reiniciar la máquina virtual, debería programar la migración del
almacenamiento de discos durante una ventana de mantenimiento existente previamente.
Si el disco es no administrado, primero debe convertirlo en un disco administrado para poder cambiar entre las
opciones de almacenamiento.
Cambio de todos los discos administrados de una máquina virtual entre

Premium y estándar
En este ejemplo se muestra cómo convertir todos los discos de una máquina virtual de almacenamiento estándar
a Premium o de almacenamiento Premium a estándar. Para usar Managed Disks premium, la máquina virtual
debe usar un Tamaño de máquina virtual que admita Premium Storage. En este ejemplo también se pasa a un
tamaño que admite Premium Storage:
# Name of the resource group that contains the VM
$rgName = 'yourResourceGroup'
# Name of the your virtual machine

$vmName = 'yourVM'
# Choose between Standard_LRS and Premium_LRS based on your scenario

# Premium capable size

# Required only if converting storage from Standard to Premium
$size = 'Standard_DS2_v2'
# Stop and deallocate the VM before changing the size

$vm = Get-AzVM -Name $vmName -resourceGroupName $rgName
# Change the VM size to a size that supports Premium storage

# Skip this step if converting storage from Premium to Standard
$vm.HardwareProfile.VmSize = $size
# Get all disks in the resource group of the VM

$vmDisks = Get-AzDisk -ResourceGroupName $rgName
# For disks that belong to the selected VM, convert to Premium storage
foreach ($disk in $vmDisks)
{
if ($disk.ManagedBy -eq $vm.Id)
{
$diskUpdateConfig = New-AzDiskUpdateConfig –AccountType $storageType
Update-AzDisk -DiskUpdate $diskUpdateConfig -ResourceGroupName $rgName `
-DiskName $disk.Name
}
}
Cambio de discos administrados individuales entre estándar y Premium

En el caso de la carga de trabajo de desarrollo y pruebas, puede que quiera tener una combinación de discos
estándar y Premium para reducir los costos. Puede optar por actualizar solamente los discos que necesitan un
rendimiento más eficaz. En este ejemplo se muestra cómo convertir un disco de una máquina virtual de
almacenamiento estándar a Premium o de almacenamiento Premium a estándar. Para usar Managed Disks
premium, la máquina virtual debe usar un Tamaño de máquina virtual que admita Premium Storage. En este
ejemplo se muestra cómo pasar a un tamaño que admite Premium Storage:
# resource group that contains the managed disk
$rgName = 'yourResourceGroupName'
# Choose between Standard_LRS and Premium_LRS based on your scenario
# Premium capable size
$size = 'Standard_DS2_v2'
# Get parent VM resource

$vmResource = Get-AzResource -ResourceId $disk.ManagedBy
# Stop and deallocate the VM before changing the storage type

Stop-AzVM -ResourceGroupName $vmResource.ResourceGroupName -Name $vmResource.Name -Force
$vm = Get-AzVM -ResourceGroupName $vmResource.ResourceGroupName -Name $vmResource.Name
# Change the VM size to a size that supports Premium storage

# Skip this step if converting storage from Premium to Standard
$vm.HardwareProfile.VmSize = $size
# Update the storage type

$diskUpdateConfig = New-AzDiskUpdateConfig -AccountType $storageType -DiskSizeGB $disk.DiskSizeGB
Start-AzVM -ResourceGroupName $vm.ResourceGroupName -Name $vm.Name
Conversión de discos administrados de estándar a Premium en Azure

Portal
Siga estos pasos:
2. Seleccione la máquina virtual de la lista de Virtual Machines en el portal.
3. Si la máquina virtual no se detiene, seleccione la opción Detener que se encuentra en la parte superior del
panel Información general de la máquina virtual y espere a que se detenga.
4. En el panel de la máquina virtual, seleccione Discos del menú.
5. Seleccione el disco que quiera convertir.
6. Seleccione Configuración del menú.
7. Cambie el Tipo de cuenta de HDD estándar a SSD Premium.
8. Haga clic en Guardar y cierre el panel de discos.
La conversión del tipo de disco es instantánea. Puede reiniciar la máquina virtual después de la conversión.
Cambio de discos administrados entre HDD estándar y SSD estándar

En este ejemplo se muestra cómo convertir un disco de una máquina virtual de HDD estándar a SSD estándar o
de SSD estándar a HDD estándar:
# resource group that contains the managed disk
$rgName = 'yourResourceGroupName'
# Choose between Standard_LRS and StandardSSD_LRS based on your scenario
$storageType = 'StandardSSD_LRS'
# Get parent VM resource

$vmResource = Get-AzResource -ResourceId $disk.ManagedBy
# Stop and deallocate the VM before changing the storage type

Stop-AzVM -ResourceGroupName $vmResource.ResourceGroupName -Name $vmResource.Name -Force
$vm = Get-AzVM -ResourceGroupName $vmResource.ResourceGroupName -Name $vmResource.Name
# Update the storage type

$diskUpdateConfig = New-AzDiskUpdateConfig -AccountType $storageType -DiskSizeGB $disk.DiskSizeGB
Start-AzVM -ResourceGroupName $vm.ResourceGroupName -Name $vm.Name
Pasos siguientes
Realice una copia de solo lectura de una máquina virtual mediante una instantánea.
Migración a Premium Storage mediante Azure Site
Recovery
Los SSD de Azure Premium le ofrecen compatibilidad con los discos de alto rendimiento y latencia baja para
máquinas virtuales (VM ) que ejecutan cargas de trabajo con muchas operaciones de E/S. Esta guía le ayuda a
migrar los discos de las máquinas virtuales desde una cuenta de almacenamiento estándar a una cuenta de
Premium Storage mediante Azure Site Recovery.
Site Recovery es un servicio de Azure que contribuye a su estrategia de continuidad empresarial y recuperación
ante desastres mediante la organización de la replicación de servidores físicos locales y máquinas virtuales en la
nube (Azure) o en un centro de datos secundario. Cuando se producen interrupciones en la ubicación principal, se
realiza la conmutación por error a la ubicación secundaria para mantener disponibles las aplicaciones y cargas de
trabajo. La conmutación por recuperación a la ubicación principal se produce cuando vuelve a su funcionamiento
normal.
Site Recovery proporciona conmutaciones por error de prueba que admiten maniobras de recuperación ante
desastres sin que los entornos de producción se vean afectados. Puede ejecutar conmutaciones por error con la
mínima pérdida de datos (según la frecuencia de replicación) para desastres inesperados. En el escenario de
migración a Premium Storage, puede utilizar la conmutación por error en Site Recovery para migrar los discos de
destino a una cuenta de Premium Storage.
Se recomienda migrar a Premium Storage mediante Site Recovery, ya que con esta opción el tiempo de inactividad
es mínimo y se evita tener ejecutar manualmente la copia los discos y la creación de nuevas máquinas virtuales.
Site Recovery de forma sistemática copiará los discos y creará nuevas máquinas virtuales durante la conmutación
por error.
Site Recovery admite varios tipos de conmutación por error con un tiempo de inactividad mínimo, o ninguno. Para
planear el tiempo de inactividad y calcular la pérdida de datos, consulte los tipos de conmutación por error de Site
Recovery. Si se prepara para conectarse a las máquinas virtuales de Azure después de la conmutación por error,
debería poder conectarse a la máquina virtual de Azure mediante RDP después de la conmutación por error.
Componentes de Azure Site Recovery
Estos componentes de Site Recovery son los relevantes para este escenario de migración:
El servidor de configuración es una máquina virtual de Azure que coordina la comunicación y administra
los procesos de replicación y recuperación de datos. En esta máquina virtual se ejecuta un archivo de
configuración individual para instalar el servidor de configuración y un componente adicional, denominado
servidor de procesos, como puerta de enlace de replicación. Lea sobre los requisitos previos del servidor de
configuración. El servidor de configuración solo se configura una vez y puede utilizarse para todas las
migraciones a la misma región.
El servidor de procesos es una puerta de enlace de replicación que:
1. Recibe datos de replicación de las máquinas virtuales de origen.
2. Optimiza los datos con el almacenamiento en caché, la compresión y cifrado.
3. Envía los datos a una cuenta de almacenamiento.
También controla la instalación de inserción del servicio de movilidad en máquinas virtuales de origen y
realiza la detección automática de máquinas virtuales de origen. El servidor de procesos predeterminado
está instalado en el servidor de configuración. Puede implementar servidores de procesos independientes
adicionales para escalar la implementación. Obtenga información sobre los procedimientos recomendados
para la implementación de servidor de procesos y la implementación de los servidores de procesos
adicionales. El servidor de procesos solo se configura una vez y puede utilizarse para todas las migraciones
a la misma región.
El servicio de movilidad es un componente que se implementa en cada máquina virtual estándar que
desea replicar. Captura las escrituras de datos en la máquina virtual estándar y los reenvía al servidor de
procesos. Más información acerca de los requisitos previos de las máquinas replicadas.
En este gráfico se muestra la interacción de estos componentes:
NOTE
Site Recovery no admite la migración de los discos de espacios de Storage.
Para conocer los componentes adicionales de otros escenarios, consulte Arquitectura del escenario.
Información esencial de Azure

Estos son los requisitos de Azure para este escenario de migración:
Una suscripción de Azure.
Una cuenta de Azure Premium Storage para almacenar los datos replicados.
Una red virtual de Azure a la que se conectarán las máquinas virtuales cuando se creen en la conmutación por
error. La red virtual de Azure debe estar en la misma región en que se ejecuta Site Recovery.
Una cuenta de almacenamiento estándar de Azure para almacenar los registros de replicación. Puede ser la
misma que para los discos de máquina virtual que se migran.
Requisitos previos
Comprender los componentes del escenario de migración relevantes de la sección anterior.
Planear el tiempo de inactividad, para lo que se debe conocer la conmutación por error en Site Recovery.
Pasos de configuración y migración

Puede usar Site Recovery para migrar máquinas virtuales de IaaS de Azure entre regiones o dentro de la misma
región. Las instrucciones siguientes se han adaptado a este escenario de migración a partir del artículo Replicación
de máquinas virtuales VMware en Azure con Site Recovery. Siga los vínculos para ver otros pasos, además de las
instrucciones de este artículo.
Paso 1: Creación de un almacén de Recovery Services
2. Seleccione Crear un recurso > Administración > Backup and Site Recovery (OMS ) . También puede
seleccionar Examinar > Almacén de Recovery Services > Agregar.
NOTE
Anteriormente, Backup y Site Recovery formaban parte de .
3. Especifique la región en la que se van a replicar las máquinas virtuales. A efectos de la migración en la misma
región, seleccione la región donde están máquinas virtuales de origen y las cuentas de almacenamiento de
origen.
Paso 2: Selección de los objetivos de protección
1. En la máquina virtual en la que desea instalar el servidor de configuración, abra Azure Portal.
2. Vaya a Almacenes de Recovery Services > Configuración > Site Recovery > Paso 1: Preparar la
infraestructura > Objetivo de protección.
3. En Objetivo de protección, en la primera lista desplegable, seleccione En Azure. En la segunda lista
desplegable, seleccione No virtualizado/Otro y, después, haga clic en Aceptar.
Paso 3: Configuración del entorno de origen (servidor de configuración)

1. Descargue Instalación unificada de Azure Site Recovery y la clave de registro del almacén, pero lo que
debe ir a los paneles Preparar infraestructura > Preparar origen > Agregar servidor.
Necesitará la clave de registro del almacén para ejecutar la instalación unificada. La clave será válida durante
cinco días a partir del momento en que se genera.
2. En el panel Agregar servidor, agregue un servidor de configuración.
3. En la máquina virtual que usa como servidor de configuración, ejecute la instalación unificada para instalar
el servidor de configuración y el servidor de procesos. Para completar la instalación, puede recorrer las
capturas de pantalla. Puede consultar las capturas de pantalla siguientes para conocer los pasos
especificados para este escenario de migración.
a. En Antes de comenzar, seleccione Install the configuration server and process server (Instalar
el servidor de configuración y el servidor de procesos).
b. En Registro, busque y seleccione la clave de registro que descargó del almacén.
c. En Detalles del entorno, seleccione si replicará máquinas virtuales de VMware. En este escenario
de migración, elija No.
4. Una vez que la instalación finalice, realice las siguientes operaciones en la ventana Servidor de
configuración de Microsoft Azure Site Recovery:
a. Utilice la pestaña Administrar cuentas para crear la cuenta que puede usar Site Recovery para la
detección automática. (En el escenario sobre cómo proteger las máquinas físicas, no es pertinente
configurar la cuenta, pero necesita al menos una cuenta para habilitar uno de los pasos siguientes. En
este caso, puede denominar a la cuenta y contraseña como cualquier otra).
b. Use la pestaña Registro del almacén para cargar el archivo de credenciales del almacén.
Paso 4: Configuración del entorno de destino

Seleccione Preparar infraestructura > Destino y especifique el modelo de implementación que desea usar para
las máquinas virtuales después de la conmutación por error. Puede elegir Clásico o Resource Manager, en
función de su escenario.
Site Recovery comprueba que tiene una o más redes y cuentas de Azure Storage compatibles.
NOTE
Si utiliza una cuenta de Premium Storage para los datos replicados, tendrá que configurar una cuenta de almacenamiento
estándar adicional para almacenar los registros de replicación.
Paso 5: Configuración de las opciones de replicación

Para comprobar que el servidor de configuración se ha asociado correctamente a la directiva de replicación que
cree, siga las instrucciones de Configuración de las opciones de replicación.
Paso 6: Planeamiento de la capacidad
1. Utilice el planeamiento de capacidad para calcular con precisión el ancho de banda de red, almacenamiento
y otros requisitos para satisfacer las necesidades de replicación.
2. Cuando haya terminado, seleccione Sí, ya lo hice en Have you completed capacity planning? (¿Ha
completado el planeamiento de capacidad?).
Paso 7: Instalación del servicio de movilidad y habilitación de la replicación
1. Puede elegir insertar la instalación en las máquinas virtuales de origen o instalar manualmente el servicio
de movilidad en las máquinas virtuales de origen. En el vínculo que se proporciona puede encontrar el
requisito de insertar la instalación y la ruta de acceso del instalador manual. Si va a realizar una instalación
manual, es posible que tenga que usar una dirección IP interna para buscar el servidor de configuración.
La máquina virtual conmutada por error tendrá dos discos temporales: uno de la máquina virtual principal y
el otro creado durante el aprovisionamiento de la máquina virtual en la región de recuperación. Para excluir
el disco temporal antes de la réplica, instale el servicio de movilidad antes de habilitar la replicación. Para
más información acerca de cómo excluir el disco temporal, consulte Exclusión de discos de la replicación.
2. Habilite la replicación como se indica a continuación:
a. Seleccione Replicar la aplicación > Origen. Después de habilitar la replicación por primera vez,
seleccione +Replicar en el almacén para habilitar la replicación de más máquinas.
b. En el paso 1, configure el valor de Origen como servidor de procesos.
c. En el paso 2, especifique el modelo de implementación posterior a la conmutación por error, la cuenta de
Premium Storage a la que se va a realizar la migración, la cuenta de almacenamiento estándar en la que
se guardarán los registros y la red virtual que producirá un error.
d. En el paso 3, agregue máquinas virtuales protegidas por dirección IP. (para buscarlas, es posible que
necesite una dirección IP interna).
e. En el paso 4, configure las propiedades mediante la selección de las cuentas que configuró anteriormente
en el servidor de procesos.
f. En el paso 5, elija la directiva de replicación que creó anteriormente en "Paso 5: Configuración de las
opciones de replicación".
g. Seleccione Aceptar.
NOTE
Cuando se cancela la asignación de una máquina virtual de Azure y se vuelve a iniciar, no hay ninguna garantía de
que obtendrá la misma dirección IP. Si la dirección IP del servidor de procesos o servidor de configuración, o de las
máquinas virtuales de Azure protegidas cambia, es posible que la replicación en este escenario no funcione
correctamente.
Cuando se diseña el entorno de Azure Storage, se recomienda utilizar cuentas de almacenamiento separadas para
cada máquina virtual en un conjunto de disponibilidad. Es recomendable seguir el procedimiento recomendado en
la capa de almacenamiento para utilizar varias cuentas de almacenamiento para cada conjunto de disponibilidad.
La distribución de discos de máquina virtual a varias cuentas de almacenamiento ayuda a mejorar la disponibilidad
de almacenamiento y distribuye la entrada/salida en toda la infraestructura de Azure Storage.
Si las máquinas virtuales están en un conjunto de disponibilidad, en lugar de replicar los discos de todas las
máquinas virtuales en una cuenta de almacenamiento, se recomienda encarecidamente migrar varias máquinas
virtuales repetidas veces. De esa forma, las máquinas virtuales del mismo conjunto de disponibilidad no
comparten una única cuenta de almacenamiento. Use el panel Habilitar la replicación para configurar una
cuenta de almacenamiento de destino para cada máquina virtual, de una en una.
Puede elegir un modelo de implementación posterior a la conmutación por error según sus necesidades. Si elige
Azure Resource Manager como modelo de implementación posterior a la conmutación por error, puede conmutar
por error una máquina virtual (Resource Manager) a una máquina virtual (Resource Manager), o bien puede
conmutar por error una máquina virtual (clásico) a una máquina virtual (Resource Manager).
Paso 8: Ejecución de una conmutación por error de prueba
Para comprobar si la replicación está completa, seleccione la instancia de Site Recovery y, después, Configuración
> Elementos replicados. Verá el estado y el porcentaje del proceso de replicación.
Cuando la replicación inicial haya finalizado, ejecute una conmutación por error de prueba para validar la estrategia
de replicación. Para ver los pasos detallados de la conmutación por error de prueba, consulte Ejecución de una
conmutación por error de prueba.
NOTE
Antes de ejecutar cualquier conmutación por error, asegúrese de que las máquinas virtuales y la estrategia de replicación
cumplen los requisitos. Para más información acerca de la ejecución de una conmutación por error de prueba, consulte
Conmutación por error de prueba a Azure en Site Recovery.
El estado de la conmutación por error de prueba se puede ver en Configuración > Trabajos >
nombreDeSuPlanDeConmutaciónPorError. En el panel, verá un desglose de los pasos y los resultados correctos o
con errores. Si se produce un error en la conmutación por error de prueba en cualquier paso, seleccione el paso
para comprobar el mensaje de error.
Paso 9: Ejecución de la conmutación por error
Después de realizada la conmutación por error de prueba, ejecute una conmutación por error para migrar los
discos a Premium Storage y replicar las instancias de máquinas virtuales. Siga los pasos detallados de Ejecución de
la conmutación por error.
No olvide seleccionar Shut down VMs and synchronize the latest data (Apagar máquinas virtuales y
sincronizar los datos más recientes). Esta opción especifica que Site Recovery debe intentar apagar las máquinas
virtuales protegidas y sincronizar los datos para que se realice la conmutación por error de la versión más reciente
de los datos. Si no selecciona esta opción o el intento es infructuoso, la conmutación por error se realizará a partir
del último punto de recuperación disponible para la máquina virtual.
Site Recovery creará una instancia de máquina virtual cuyo tipo sea el mismo, o similar, a una máquina virtual que
pueda usar Premium Storage. Puede comprobar el rendimiento y el precio de varias instancias de máquinas
virtuales en Precios de máquinas virtuales Windows o Precios de máquinas virtuales Linux.
Pasos posteriores a la migración

1. Configure máquinas virtuales replicadas en el conjunto de disponibilidad, si procede. Site Recovery
no admite la migración de máquinas virtuales junto con el conjunto de disponibilidad. Dependiendo de la
implementación de la máquina virtual replicada, realice una de las siguientes acciones:
Para una VM creada con el modelo de implementación clásica: agregue la VM al conjunto de
disponibilidad en Azure Portal. Para ver los pasos detallados, consulte Adición de una máquina virtual
existente a un conjunto de disponibilidad.
Para una VM creada con el modelo de implementación de Resource Manager: guarde la configuración de
la VM y, después, elimine y vuelva a crear las VM en el conjunto de disponibilidad. Para ello, use el script
que encontrará en Set Azure Resource Manager VM Availability Set (Establecimiento del conjunto de
disponibilidad de máquinas virtuales de Azure Resource Manager). Antes de ejecutar este script,
compruebe sus limitaciones y planee el tiempo de inactividad.
2. Elimine las máquinas virtuales y los discos antiguos. Asegúrese de que los discos Premium sean
coherentes con los discos de origen y que las nuevas máquinas virtuales realizan la misma función que las
máquinas virtuales de origen. Elimine la máquina virtual y los discos de las cuentas de almacenamiento de
origen en Azure Portal. Si hay un problema en el que el disco no se elimina aunque haya eliminado la
máquina virtual, consulte Troubleshoot storage resource deletion errors (Solución de errores de eliminación
de recursos de almacenamiento).
3. Limpie la infraestructura de Azure Site Recovery. Si Site Recovery deja de necesitarse, puede limpiar su
infraestructura. Elimine los elementos duplicados, el servidor de configuración y la directiva de recuperación
y, después, elimine el almacén de Azure Site Recovery.
solución de problemas
Protección de supervisión y solución de problemas para las máquinas virtuales y los servidores físicos
Foro de Microsoft Azure Site Recovery
Pasos siguientes
Para conocer los escenarios concretos para migrar máquinas virtuales, consulte los siguientes recursos:
Migrar Azure Virtual Machines entre cuentas de almacenamiento
Crear y cargar un VHD de Windows Server a Azure
Migrar máquinas virtuales de Amazon AWS a Microsoft Azure
Consulte también los siguientes recursos para más información sobre Azure Storage y Azure Virtual Machines:
Azure Storage
Azure Virtual Machines
Migración de VM de Azure a Managed Disks en
Azure
Azure Managed Disks simplifica la administración de almacenamiento al eliminar la necesidad de administrar

cuentas de almacenamiento por separado. También puede migrar las VM de Azure existentes a Managed Disks
para aprovechar la mejor confiabilidad de las VM en un conjunto de disponibilidad. De esta forma, se garantiza que
los discos de las distintas máquinas virtuales de un conjunto de disponibilidad estén lo suficientemente aisladas
entre sí como para evitar un único punto de error. Coloca automáticamente discos de distintas VM en un conjunto
de disponibilidad en unidades de escalado de almacenamiento diferentes (marcas de tiempo), lo que limita el
impacto de errores únicos de unidad de escalado de almacenamiento generados debido a errores de hardware y
software. En virtud de sus necesidades, puede elegir entre cuatro tipos de opciones de almacenamiento. Para
información acerca de los tipos de disco disponibles, consulte nuestro artículo Selección de un tipo de disco.
Escenarios de migración
Puede migrar a Managed Disks en los escenarios siguientes:
ESCENARIO ARTÍCULO
Conversión de VM independientes y VM de un conjunto de Conversión de VM para usar discos administrados

disponibilidad para establecer discos administrados
Conversión de una sola máquina virtual del modelo clásico a Creación de una VM desde un disco duro virtual clásico
Resource Manager en discos administrados
Conversión de todas las máquinas virtuales de una red virtual Migración de recursos de IaaS desde el modelo clásico a
desde el modelo clásico a Resource Manager en discos Resource Manager y luego Conversión de una VM desde
administrados discos no administrados a discos administrados
Actualización de las máquinas virtuales con discos no En primer lugar, convierta una máquina virtual Windows con
administrados estándar a máquinas virtuales con discos discos no administrados a discos administrados. Después,
administrados prémium actualice el tipo de almacenamiento de un disco administrado.
Pasos siguientes
Más información sobre Managed Disks
Revise el precio de Managed Disks.
Conversión de máquina virtual Windows con discos
no administrados en discos administrados
Si ya dispone de máquinas virtuales Windows que usan discos no administrados, puede convertirlas para usar
discos administrados mediante el servicio Azure Managed Disks. Este proceso convierte el disco del SO y los
discos de datos conectados.
Antes de empezar
Revise Planeación de la migración a Managed Disks.
Revise las preguntas frecuentes sobre la migración a Managed Disks.
La conversión requiere reiniciar la máquina virtual, por lo que debe programar la migración de las
máquinas virtuales durante una ventana de mantenimiento existente previamente.
La conversión no es reversible.
Tenga en cuenta que los usuarios con el rol Colaborador de la máquina virtual no podrán cambiar el
tamaño de la máquina virtual (como lo hacían antes de la conversión). El motivo es que las máquinas
virtuales con discos administrados requieren que el usuario tenga el permiso de
escritura/discos/Microsoft.Compute para los discos del sistema operativo.
Asegúrese de probar la conversión. Migre una máquina virtual de prueba antes de realizar la migración
en producción.
Durante la conversión, se desasigna la VM. La VM recibe una nueva dirección IP cuando se inicia
después de la conversión. Si es necesario, puede asignar una dirección IP estática a la máquina virtual.
Revise la versión mínima del agente de máquina virtual de Azure necesario para admitir el proceso de
conversión. Para más información acerca de cómo comprobar y actualizar la versión del agente, consulte
Soporte de versión mínima para los agentes de la máquina virtual en Azure
No se eliminan los discos duros virtuales originales ni la cuenta de almacenamiento usada por la máquina
virtual antes de la conversión. Seguirán acumulando cargos. Para evitar que se le facture por estos artefactos,
elimine los blobs de los discos duros virtuales originales después de comprobar que la conversión esté
completa. Si tiene que buscar estos discos no conectados con el fin de eliminarlos, consulte nuestro artículo
Búsqueda y eliminación de discos administrados y no administrados de Azure no conectados.
Conversión de máquinas virtuales de instancia única

En esta sección se explica cómo convertir máquinas virtuales de Azure de instancia única de Unmanaged Disks
a Managed Disks. (Si las máquinas virtuales se encuentran en un conjunto de disponibilidad, consulte la sección
siguiente).
1. Desasigne la VM con el cmdlet Stop-AzVM. En el ejemplo siguiente se desasigna la VM myVM en el
grupo de recursos denominado myResourceGroup :
$vmName = "myVM"
2. Convierta la VM a discos administrados con el cmdlet ConvertTo-AzVMManagedDisk. El proceso

siguiente convierte la VM anterior, incluidos el disco del SO y todos los discos de datos, e inicia la
máquina virtual:
ConvertTo-AzVMManagedDisk -ResourceGroupName $rgName -VMName $vmName
Conversión de VM de un conjunto de disponibilidad

Si las VM que desea convertir en discos administrados se encuentran en un conjunto de disponibilidad, primero
debe convertir el conjunto de disponibilidad en un conjunto de disponibilidad administrado.
1. Convierta el conjunto de disponibilidad con el cmdlet Update-AzAvailabilitySet. En el ejemplo siguiente
se actualiza el conjunto de disponibilidad denominado myAvailabilitySet en el grupo de recursos con
nombre myResourceGroup :
$avSetName = 'myAvailabilitySet'
$avSet = Get-AzAvailabilitySet -ResourceGroupName $rgName -Name $avSetName

Update-AzAvailabilitySet -AvailabilitySet $avSet -Sku Aligned
Si la región en que se encuentra el conjunto de disponibilidad solo tiene 2 dominios de error

administrados, pero el número de dominios de error no administrados es 3, este comando muestra un
error similar a "El número de dominios de error especificado 3 debe estar en el intervalo de 1 a 2". Para
resolver el error, actualice el dominio predeterminado a 2 y actualice Sku a Aligned como sigue:
$avSet.PlatformFaultDomainCount = 2
Update-AzAvailabilitySet -AvailabilitySet $avSet -Sku Aligned
2. Desasigne y convierta las máquinas virtuales del conjunto de disponibilidad. El siguiente script desasigna
cada VM mediante el cmdlet Stop-AzVM, la convierte con ConvertTo-AzVMManagedDisk y la reinicia
automáticamente como parte del proceso de conversión:
$avSet = Get-AzAvailabilitySet -ResourceGroupName $rgName -Name $avSetName
foreach($vmInfo in $avSet.VirtualMachinesReferences)
{
$vm = Get-AzVM -ResourceGroupName $rgName | Where-Object {$_.Id -eq $vmInfo.id}
Stop-AzVM -ResourceGroupName $rgName -Name $vm.Name -Force
ConvertTo-AzVMManagedDisk -ResourceGroupName $rgName -VMName $vm.Name
}
solución de problemas
Si se produce un error durante la conversión, o si una máquina virtual presenta un estado de error debido a
errores en una conversión anterior, ejecute el cmdlet ConvertTo-AzVMManagedDisk de nuevo. Normalmente, un
simple reintento desbloquea la situación. Antes de realizar la conversión, asegúrese de que todas las extensiones
de máquina virtual se encuentran en el estado de "Aprovisionamiento realizado correctamente". De lo contrario,
se producirá un error de conversión con el código de error 409.
Conversión mediante Azure Portal

Puede convertir discos no administrados en discos administrados mediante Azure Portal.
2. Seleccione la máquina virtual en la lista de máquinas virtuales en el portal.
3. En la hoja de la máquina virtual, seleccione Discos en el menú.
4. En la parte superior de la hoja Discos, seleccione Migrar a discos administrados.
5. Si la máquina virtual está en un conjunto de disponibilidad, habrá una advertencia en la hoja Migrar a
discos administrados indicándole que debe convertir el conjunto de disponibilidad primero. La advertencia
debería tener un vínculo en el que puede hacer clic para convertir el conjunto de disponibilidad. Una vez que
se convierta el conjunto de disponibilidad o la máquina virtual no esté en un conjunto de disponibilidad,
haga clic en Migrar para iniciar el proceso de migración de los discos a discos administrados.
La máquina virtual se detendrá y se reiniciará una vez completada la migración.
Pasos siguientes
Conversión de Managed Disks estándar a premium
Realice una copia de solo lectura de una máquina virtual mediante instantáneas.
Habilitar el acelerador de escritura
El Acelerador de escritura es una capacidad de disco para las máquinas virtuales (VM ) de la serie M en Premium
Storage con Azure Managed Disks exclusivamente. Como el nombre indica, el propósito de la funcionalidad es
mejorar la latencia de E/S de las escrituras en Azure Premium Storage. El Acelerador de escritura se adecua
perfectamente a las situaciones en las que las actualizaciones del archivo de registro deben persistir en el disco de
una manera muy eficiente para bases de datos modernas.
En general, el Acelerador de escritura está disponible para VM de serie la M en la nube pública.
Planeación del uso del Acelerador de escritura

El Acelerador de escritura se debe usar para los volúmenes que contienen el registro de transacciones o los
registros de puestas al día de un DBMS. No se recomienda utilizar el Acelerador de escritura para los volúmenes
de datos de un DBMS, ya que la característica se ha optimizado para su uso en los discos de registro.
El Acelerador de escritura solo funciona en conjunto con Azure Managed Disks.
IMPORTANT
La habilitación del Acelerador de escritura para el disco del sistema operativo de la máquina virtual hará que esta se reinicie.
Para habilitar el Acelerador de escritura en un disco existente de Azure que NO forme parte de un volumen compuesto de
varios discos con administradores de volúmenes o discos de Windows, espacios de almacenamiento de Windows, servidor de
archivos de escalabilidad horizontal (SOFS) de Windows, LVM o MDADM de Linux, la carga de trabajo que accede al disco de
Azure debe estar apagada. Las aplicaciones de base de datos que usan el disco de Azure DEBEN estar apagadas.
Si desea habilitar o deshabilitar el Acelerador de escritura para un volumen existente que conste de varios discos de Azure
Premium Storage y se segmente con administradores de volúmenes o discos de Windows, espacios de almacenamiento de
Windows, servidor de archivos de escalabilidad horizontal (SOFS) de Windows, LVM o MDADM de Linux, todos los discos que
componen el volumen se deben habilitar o deshabilitar para el Acelerador de escritura en pasos independientes. Antes de
habilitar o deshabilitar el Acelerador de escritura en este tipo de configuración, apague la máquina virtual de
Azure.
La habilitación del Acelerador de escritura para los discos de sistema operativo no debería ser necesaria para las
configuraciones de máquinas virtuales relacionadas con SAP.
Restricciones del uso del Acelerador de escritura
Estas restricciones se aplican al usar el Acelerador de escritura para un VHD o disco de Azure:
El almacenamiento en caché de discos Premium debe establecerse en "Ninguno" o "Solo lectura". No se admite
ningún otro modo de almacenamiento en caché.
Actualmente, los discos con el Acelerador de escritura habilitado no admiten las instantáneas. Durante la copia
de seguridad, el servicio Azure Backup excluye automáticamente los discos con el Acelerador de escritura
habilitado conectados a la VM.
Solo los tamaños de E/S más pequeños (<=512 KiB ) toman la ruta de acceso acelerada. En situaciones de carga
de trabajo donde los datos se cargan de forma masiva o donde los búferes de registros de transacción de los
diferentes sistemas de administración de bases de datos (DBMS ) se llenan hasta un mayor grado antes de
conservarse en el almacenamiento, existe la probabilidad de que la E/S escrita en el disco no tome la ruta de
acceso acelerada.
Hay límites en los discos duros virtuales de Azure Premium Storage por máquina virtual que el Acelerador de
escritura puede admitir. Los límites actuales son:
NÚMERO DE DISCOS DE ACELERADOR DE IOPS DE DISCOS DE ACELERADOR DE

SKU DE LA MÁQUINA VIRTUAL ESCRITURA ESCRITURA POR MÁQUINA VIRTUAL
M208ms_v2, M208s_v2 8 10000
M128ms, 128s 16 20000
M64ms, M64ls, M64s 8 10000
M32ms, M32ls, M32ts, M32s 4 5000
M16ms, M16s 2 2.500
M8ms, M8s 1 1250
Los límites de IOPS son por máquina virtual y no por disco. Todos los discos del Acelerador de escritura
comparten el mismo límite de IOPS por máquina virtual.
Habilitación del Acelerador de escritura en un disco específico

En las secciones siguientes se describe cómo el Acelerador de escritura se pueden habilitar en los VHD de Azure
Premium Storage.
Requisitos previos
En este momento, los requisitos previos siguientes se aplican al uso del Acelerador de escritura:
Los discos en los que desea aplicar el Acelerador de escritura de Azure deben ser Azure Managed Disks en
Premium Storage.
Debe usar una máquina virtual de la serie M
Habilitación del Acelerador de escritura mediante Azure PowerShell

El módulo de Azure PowerShell a partir de la versión 5.5.0 incluye los cambios en los cmdlets pertinentes para
habilitar o deshabilitar el Acelerador de escritura para discos específicos de Azure Premium Storage. Con el fin de
habilitar o implementar los discos compatibles con el Acelerador de escritura, se modificaron los comandos de
PowerShell siguientes y se extendieron para que aceptaran un parámetro para el Acelerador de escritura.
Se ha agregado -WriteAccelerator, un nuevo parámetro de modificador, a los siguientes cmdlets:
Set-AzVMOsDisk
Add-AzVMDataDisk
Set-AzVMDataDisk
Add-AzVmssDataDisk
Si no se proporciona el parámetro, la propiedad se establece en false y se implementarán discos no compatibles
con el Acelerador de escritura.
Se agregó -OsDiskWriteAccelerator, un nuevo parámetro de modificador, a los siguientes cmdlets:
Set-AzVmssStorageProfile
Si no se especifica el parámetro, la propiedad se establece en false de forma predeterminada y se devuelven los
discos que no usan el Acelerador de escritura.
Se agregó -OsDiskWriteAccelerator, un nuevo parámetro booleano opcional (que no admite valores NULL ), a
los siguientes cmdlets:
Update-AzVM
Update-AzVmss
Especifique $true o $false para controlar la compatibilidad del Acelerador de escritura con los discos.
Algunos ejemplos de los comandos podrían ser:
New-AzVMConfig | Set-AzVMOsDisk | Add-AzVMDataDisk -Name "datadisk1" | Add-AzVMDataDisk -Name "logdisk1" -

WriteAccelerator | New-AzVM
Get-AzVM | Update-AzVM -OsDiskWriteAccelerator $true
New-AzVmssConfig | Set-AzVmssStorageProfile -OsDiskWriteAccelerator | Add-AzVmssDataDisk -Name "datadisk1" -

WriteAccelerator:$false | Add-AzVmssDataDisk -Name "logdisk1" -WriteAccelerator | New-AzVmss
Get-AzVmss | Update-AzVmss -OsDiskWriteAccelerator:$false
Se pueden ejecutar dos escenarios principales mediante scripts, tal como se muestra en las secciones siguientes.
Incorporación de un disco nuevo compatible con el Acelerador de escritura utilizando PowerShell
Puede usar este script para agregar un disco nuevo a la máquina virtual. El disco que se crea con este script usa el
Acelerador de escritura.
Reemplace myVM , myWAVMs , log001 , el tamaño del disco y el LunID del disco con los valores adecuados para su
implementación.
# Specify your VM Name

$vmName="myVM"
#Specify your Resource Group
$rgName = "myWAVMs"
#data disk name
$datadiskname = "log001"
#LUN Id
$lunid=8
#size
$size=1023
#Pulls the VM info for later
$vm=Get-AzVM -ResourceGroupName $rgname -Name $vmname
#add a new VM data disk
Add-AzVMDataDisk -CreateOption empty -DiskSizeInGB $size -Name $vmname-$datadiskname -VM $vm -Caching None -
WriteAccelerator:$true -lun $lunid
#Updates the VM with the disk config - does not require a reboot
Update-AzVM -ResourceGroupName $rgname -VM $vm
Habilitación del Acelerador de escritura en un disco de Azure existente utilizando PowerShell

Pueden usar este script para habilitar el Acelerador de escritura en un disco existente. Reemplace myVM , myWAVMs y
test-log001 con los valores adecuados para su implementación. El script agrega el Acelerador de escritura a un
disco existente cuando el valor de $newstatus está establecido en "$true". Si usa el valor "$false", el Acelerador de
escritura se deshabilitará en un disco determinado.
#Specify your VM Name
$vmName="myVM"
#Specify your Resource Group
$rgName = "myWAVMs"
#data disk name
$datadiskname = "test-log001"
#new Write Accelerator status ($true for enabled, $false for disabled)
$newstatus = $true
#Pulls the VM info for later
$vm=Get-AzVM -ResourceGroupName $rgname -Name $vmname
#add a new VM data disk
Set-AzVMDataDisk -VM $vm -Name $datadiskname -Caching None -WriteAccelerator:$newstatus
#Updates the VM with the disk config - does not require a reboot
Update-AzVM -ResourceGroupName $rgname -VM $vm
NOTE
Si ejecuta el script anterior, desconectará el disco especificado, habilitará el Acelerador de escritura en el disco y, luego, lo
volverá a adjuntar.
Habilitación del Acelerador de escritura mediante Azure Portal

Puede habilitar el Acelerador de escritura a través del portal, donde especifique la configuración de caché del disco:
Habilitación del Acelerador de escritura mediante la CLI de Azure

Puede usar la CLI de Azure para habilitar el acelerador de escritura.
Para habilitar el Acelerador de escritura en un disco existente, use az vm update. Puede usar los siguientes
ejemplos si sustituye los valores diskName, VMName y ResourceGroup por los suyos propios:
az vm update -g group1 -n vm1 -write-accelerator 1=true
Para conectar un disco con el Acelerador de escritura habilitado, use az vm disk attach, puede utilizar el ejemplo
siguiente si sustituye los valores por los suyos propios:
az vm disk attach -g group1 -vm-name vm1 -disk d1 --enable-write-accelerator
Para deshabilitar el Acelerador de escritura, use az vm update, estableciendo las propiedades en false:
az vm update -g group1 -n vm1 -write-accelerator 0=false 1=false
Habilitación del Acelerador de escritura mediante las API REST
Para implementar a través de la API REST de Azure, necesita instalar ARMclient de Azure.
Instalación de ARMclient
Para ejecutar ARMclient, debe instalarlo a través de Chocolatey. Puede instalarlo a través de cmd.exe o PowerShell.
Use derechos elevados para estos comandos ("Ejecutar como administrador").
Con cmd.exe, ejecute este comando:
@"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -InputFormat None -ExecutionPolicy
Bypass -Command "iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))"
&& SET "PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin"
Con PowerShell, ejecute este comando:

Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object
System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
Ahora puede instalar armclient con el siguiente comando en cmd.exe o PowerShell choco install armclient
Obtención de la configuración de la máquina virtual actual

Para cambiar los atributos de la configuración de disco, primero debe obtener la configuración actual en un archivo
JSON. Puede obtener la configuración actual ejecutando el siguiente comando:
armclient GET /subscriptions/<<subscription-
ID<</resourceGroups/<<ResourceGroup>>/providers/Microsoft.Compute/virtualMachines/<<virtualmachinename>>?api-
version=2017-12-01 > <<filename.json>>
Reemplace los términos dentro de "<< >>" con los datos, incluido el nombre que debe tener el archivo JSON.
La salida debería parecerse a esta:
{
"properties": {
"vmId": "2444c93e-f8bb-4a20-af2d-1658d9dbbbcb",
"vmSize": "Standard_M64s"
},
"storageProfile": {
"imageReference": {
"publisher": "SUSE",
"offer": "SLES-SAP",
"sku": "12-SP3",
"version": "latest"
},
"osDisk": {
"osType": "Linux",
"name": "mylittlesap_OsDisk_1_754a1b8bb390468e9b4c429b81cc5f5a",
"managedDisk": {
"storageAccountType": "Premium_LRS",
"id":
"/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/mylittlesap/providers/Microsoft.Compute/dis
ks/mylittlesap_OsDisk_1_754a1b8bb390468e9b4c429b81cc5f5a"
},
"diskSizeGB": 30
},
"dataDisks": [
{
"lun": 0,
"name": "data1",
"createOption": "Attach",
"caching": "None",
"managedDisk": {
"id":
ks/data1"
},
"diskSizeGB": 1023
},
{
"lun": 1,
"name": "log1",
"caching": "None",
"managedDisk": {
"id":
ks/data2"
},
"diskSizeGB": 1023
}
]
},
"osProfile": {
"computerName": "mylittlesapVM",
"adminUsername": "pl",
"linuxConfiguration": {
"disablePasswordAuthentication": false
},
"secrets": []
},
"networkProfile": {
{
"id":
"/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/mylittlesap/providers/Microsoft.Network/net
workInterfaces/mylittlesap518"
}
]
},
"enabled": true,
"storageUri": "https://mylittlesapdiag895.blob.core.windows.net/"
}
},
"provisioningState": "Succeeded"
},
"location": "westeurope",
"id":
"/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/mylittlesap/providers/Microsoft.Compute/vir
tualMachines/mylittlesapVM",
"name": "mylittlesapVM"
Después, actualice el archivo JSON y habilite el Acelerador de escritura en el disco llamado "log1". Para ello,
agregue este atributo en el archivo JSON después de la entrada de caché del disco.
{
"lun": 1,
"name": "log1",
"caching": "None",
"writeAcceleratorEnabled": true,
"managedDisk": {
"id":
ks/data2"
},
"diskSizeGB": 1023
}
Luego, actualice la implementación existente con este comando:

armclient PUT /subscriptions/<<subscription-
ID<</resourceGroups/<<ResourceGroup>>/providers/Microsoft.Compute/virtualMachines/<<virtualmachinename>>?api-
version=2017-12-01 @<<filename.json>>
La salida debe parecerse a la que aparece a continuación. Puede ver que el Acelerador de escritura está habilitado
para un disco.
{
"properties": {
"vmId": "2444c93e-f8bb-4a20-af2d-1658d9dbbbcb",
"vmSize": "Standard_M64s"
},
"storageProfile": {
"imageReference": {
"publisher": "SUSE",
"offer": "SLES-SAP",
"sku": "12-SP3",
"version": "latest"
},
"osDisk": {
"osType": "Linux",
"name": "mylittlesap_OsDisk_1_754a1b8bb390468e9b4c429b81cc5f5a",
"managedDisk": {
"id":
ks/mylittlesap_OsDisk_1_754a1b8bb390468e9b4c429b81cc5f5a"
},
"diskSizeGB": 30
},
"dataDisks": [
{
"lun": 0,
"name": "data1",
"caching": "None",
"managedDisk": {
"id":
ks/data1"
},
"diskSizeGB": 1023
},
{
"lun": 1,
"name": "log1",
"name": "log1",
"caching": "None",
"writeAcceleratorEnabled": true,
"managedDisk": {
"id":
ks/data2"
},
"diskSizeGB": 1023
}
]
},
"osProfile": {
"computerName": "mylittlesapVM",
"adminUsername": "pl",
"linuxConfiguration": {
"disablePasswordAuthentication": false
},
"secrets": []
},
"networkProfile": {
{
"id":
"/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/mylittlesap/providers/Microsoft.Network/net
workInterfaces/mylittlesap518"
}
]
},
"enabled": true,
"storageUri": "https://mylittlesapdiag895.blob.core.windows.net/"
}
},
"provisioningState": "Succeeded"
},
"location": "westeurope",
"id":
"/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/mylittlesap/providers/Microsoft.Compute/vir
tualMachines/mylittlesapVM",
"name": "mylittlesapVM"
Una vez haya hecho el cambio, la unidad debería admitir el Acelerador de escritura.
Uso de discos Ultra de Azure
Los discos Ultra de Azure ofrecen un alto rendimiento, IOPS elevadas y un almacenamiento en disco coherente y
de baja latencia para máquinas virtuales IaaS de Azure. En esta nueva oferta se proporciona un rendimiento
exclusivo que se encuentra en los mismos niveles de disponibilidad que nuestras ofertas de discos existentes. Una
ventaja importante de los discos Ultra es la posibilidad de cambiar dinámicamente el rendimiento del disco SSD
junto con sus cargas de trabajo sin tener que reiniciar las máquinas virtuales. Además, los discos Ultra son
adecuados para cargas de trabajo con grandes cantidades de datos, como SAP HANA, bases de datos de nivel
superior y cargas de trabajo que admitan muchas transacciones.
Ámbito y limitaciones de la disponibilidad general

Por ahora, los discos Ultra tienen limitaciones adicionales, como se indica a continuación:
Se admiten en las siguientes regiones, con un número variable de zonas de disponibilidad por región:
Este de EE. UU. 2
East US
Oeste de EE. UU. 2
Sudeste Asiático
Europa del Norte
Europa occidental
Sur de Reino Unido 2
Solo se podrán usar con las zonas de disponibilidad (los conjuntos de disponibilidad y las implementaciones de
máquinas virtuales únicas fuera de las zonas no tendrán la capacidad de adjuntar un disco Ultra).
Solo se admiten en las siguientes series de máquinas virtuales:
ESv3
DSv3
FSv2
M
Mv2
No todos los tamaños de máquina virtual están disponibles en todas las regiones admitidas con discos Ultra.
Solo están disponibles como discos de datos y solo admiten el tamaño de sector físico 4k.
Solo pueden crearse como discos vacíos.
Todavía no admiten instantáneas de disco, imágenes de máquinas virtuales, conjuntos de disponibilidad ni
Todavía no admiten la integración con Azure Backup o Azure Site Recovery.
El límite máximo actual de IOPS en máquinas virtuales de disponibilidad general es 80 000.
Determinar el tamaño de la máquina virtual y la disponibilidad por

región
Para aprovechar los discos Ultra, debe determinar en qué zona de disponibilidad se encuentra. No todas las
regiones admiten todos los tamaños de máquina virtual con discos Ultra. Para determinar si la región, la zona y el
tamaño de la máquina virtual admiten discos Ultra, ejecute cualquiera de los siguientes comandos y asegúrese de
reemplazar primero los valores region, vmSize y subscription:
CLI:
$subscription = "<yourSubID>"
$region = "<yourLocation>, example value is southeastasia"
$vmSize = "<yourVMSize>, example value is Standard_E64s_v3"
az vm list-skus --resource-type virtualMachines --location $region --query "[?

name=='$vmSize'].locationInfo[0].zoneDetails[0].Name" --subscription $subscription
PowerShell:
$region = "southeastasia"
$vmSize = "Standard_E64s_v3"
(Get-AzComputeResourceSku | where {$_.Locations.Contains($region) -and ($_.Name -eq $vmSize) -and
$_.LocationInfo[0].ZoneDetails.Count -gt 0})[0].LocationInfo[0].ZoneDetails
La respuesta será similar al formulario siguiente, donde X es la zona que se utilizará para la implementación en la
región elegida. X podría ser 1, 2 o 3.
Conserve el valor de Zones, ya que representa la zona de disponibilidad y la necesitará para implementar un
disco Ultra.
RESOURCETYPE NOMBRE LOCATION ZONES RESTRICCIÓN CAPACIDAD VALOR
disks UltraSSD_LRS eastus2 X
NOTE
Si no ha habido respuesta del comando, el tamaño de máquina virtual seleccionado no es compatible con los discos Ultra en
la región seleccionada.
Ahora que sabe en qué zona se va a realizar la implementación, siga los pasos de implementación de este artículo
para implementar una máquina virtual con un disco Ultra conectado o conectar un disco Ultra a una máquina
virtual existente.
Implementación de un disco Ultra con Azure Resource Manager

En primer lugar, determine el tamaño de la máquina virtual que se va a implementar. Para obtener una lista de los
tamaños de máquina virtual admitidos, vea la sección Ámbito y limitaciones de la disponibilidad general.
Si quiere crear una máquina virtual con varios discos Ultra, vea el ejemplo Creación de una máquina virtual con
varios discos Ultra.
Si piensa usar su propia plantilla, asegúrese de que apiVersion para Microsoft.Compute/virtualMachines y
Microsoft.Compute/Disks se establece como 2018-06-01 (o posterior ).
Establezca la SKU de disco en UltraSSD_LRS, luego establezca la capacidad de disco, IOPS, zona de
disponibilidad y rendimiento en MBps para crear un disco ultra.
Cuando se aprovisiona la máquina virtual, puede realizar una partición y dar formato a los discos de datos y
configurarlos para las cargas de trabajo.
Implementación de disco Ultra mediante Azure Portal

En esta sección se describe la implementación de una máquina virtual equipada con un disco Ultra como disco de
datos. Se supone que está familiarizado con la implementación de una máquina virtual; si no lo está, consulte
Inicio rápido: crear una máquina virtual de Windows en Azure Portal.
Inicie sesión en Azure Portal y navegue hasta Implementar una máquina virtual (VM ).
Asegúrese de elegir un tamaño y región compatibles de máquina virtual.
Seleccione Zona de disponibilidad en Opciones de disponibilidad.
Rellene las entradas restantes con las selecciones de su elección.
Seleccione Discos.
En la hoja Discos, seleccione Sí para Habilitar compatibilidad con Ultra Disks.

Seleccione Crear y adjuntar un nuevo disco para conectar un disco Ultra ahora.
En la hoja Crear un disco, escriba un nombre y, a continuación, seleccione Cambiar tamaño.

Cambie Tipo de cuenta a Disco Ultra.
Cambie los valores de Tamaño de disco personalizado (GiB ) , IOPS del disco y Rendimiento de disco
por los de su elección.
Seleccione Aceptar en ambas hojas.
Continúe con la implementación de la máquina virtual, será igual a cómo implementaría cualquier otra
máquina virtual.
Adjuntar un disco Ultra mediante Azure Portal

Como alternativa, si la máquina virtual existente se encuentra en una región o zona de disponibilidad que puede
usar discos Ultra, puede usar este tipo de discos sin tener que crear una nueva máquina virtual. Para ello, habilite
los discos Ultra en la máquina virtual existente y, a continuación, asócielos como discos de datos.
Navegue hasta la máquina virtual y seleccione Discos.
Seleccione Editar.
Seleccione Sí para Habilitar compatibilidad con Ultra Disks.
Seleccione Guardar.
Seleccione Agregar disco de datos y, en la lista desplegable, para Nombre seleccione Crear disco.
Escriba un nombre para el nuevo disco y, a continuación, seleccione Cambiar el tamaño.
Cambie Tipo de cuenta a Disco Ultra.
Cambie los valores de Tamaño de disco personalizado (GiB ) , IOPS del disco y Rendimiento de disco
por los de su elección.
Seleccione Aceptar y después Crear.
Cuando vuelva a la hoja del disco, seleccione Guardar.
Ajustar del rendimiento de un disco Ultra mediante Azure Portal

Los discos Ultra ofrecen una capacidad única que permite ajustar su rendimiento. Puede realizar estos ajustes
desde Azure Portal, en los propios discos.
Navegue hasta la máquina virtual y seleccione Discos.
Seleccione el disco Ultra en el que desea modificar el rendimiento.
Seleccione Configuración y, a continuación, realice las modificaciones.

Seleccione Guardar.
Implementación de un disco Ultra mediante la CLI
En primer lugar, determine el tamaño de la máquina virtual que se va a implementar. Vea la sección Ámbito y
limitaciones de la disponibilidad general para obtener una lista de los tamaños de máquina virtual admitidos.
Para conectar un disco Ultra, debe crear una máquina virtual que pueda usar discos Ultra.
Reemplace o establezca las variables $vmname, $rgname, $diskname, $location, $password y $user con sus
propios valores. Establezca $zone en el valor de la zona de disponibilidad que ha obtenido al inicio de este
artículo. Después, ejecute el siguiente comando de la CLI para crear una máquina virtual habilitada para ultra:
az vm create --subscription $subscription -n $vmname -g $rgname --image Win2016Datacenter --ultra-ssd-enabled

true --zone $zone --authentication-type password --admin-password $password --admin-username $user --size
Standard_D4s_v3 --location $location
Creación de un disco Ultra mediante la CLI

Ahora que ya tiene una máquina virtual en la que se pueden colocar discos Ultra, puede crear un disco Ultra y
conectarlo a dicha máquina virtual.
$location="eastus2"
$subscription="xxx"
$rgname="ultraRG"
$diskname="ssd1"
$vmname="ultravm1"
$zone=123
#create an ultra disk

az disk create `
--subscription $subscription `
-n $diskname `
-g $rgname `
--size-gb 4 `
--location $location `
--zone $zone `
--sku UltraSSD_LRS `
--disk-iops-read-write 1000 `
--disk-mbps-read-write 50
Conexión de un disco Ultra a una máquina virtual mediante la CLI

usar discos Ultra, puede usar este tipo de discos sin tener que crear una nueva máquina virtual.
$rgName = "<yourResourceGroupName>"
$vmName = "<yourVMName>"
$diskName = "<yourDiskName>"
$subscriptionId = "<yourSubscriptionID>"
az vm disk attach -g $rgName --vm-name $vmName --disk $diskName --subscription $subscriptionId
Ajuste del rendimiento de un disco Ultra mediante la CLI

Los discos Ultra ofrecen una capacidad única que permite ajustar su rendimiento. El comando siguiente describe
cómo se usa esta característica:
az disk update `
--subscription $subscription `
--resource-group $rgname `
--name $diskName `
--set diskIopsReadWrite=80000 `
--set diskMbpsReadWrite=800
Implementación de un disco Ultra mediante PowerShell

En primer lugar, determine el tamaño de la máquina virtual que se va a implementar. Vea la sección Ámbito y
limitaciones de la disponibilidad general para obtener una lista de los tamaños de máquina virtual admitidos.
Para usar discos Ultra, debe crear una máquina virtual que sea capaz de usar discos Ultra. Reemplace o establezca
las variables $resourcegroup y $vmName con sus propios valores. Establezca $zone en el valor de la zona de
disponibilidad que ha obtenido al inicio de este artículo. Después, ejecute el siguiente comando de New -AzVm
para crear una máquina virtual ultra habilitada:
New-AzVm `
-ResourceGroupName $resourcegroup `
-Name $vmName `
-Location "eastus2" `
-Image "Win2016Datacenter" `
-EnableUltraSSD `
-size "Standard_D4s_v3" `
-zone $zone
Creación de un disco Ultra mediante PowerShell

Ahora que ya tiene una máquina virtual que puede usar discos Ultra, puede crear un disco Ultra y conectarlo a
dicha máquina virtual:
$diskconfig = New-AzDiskConfig `
-Location 'EastUS2' `
-DiskSizeGB 8 `
-DiskIOPSReadWrite 1000 `
-DiskMBpsReadWrite 100 `
-AccountType UltraSSD_LRS `
-CreateOption Empty `
-zone $zone;
New-AzDisk `
-DiskName 'Disk02' `
-Disk $diskconfig;
Conexión de un disco Ultra a una máquina virtual mediante PowerShell

usar discos Ultra, puede usar este tipo de discos sin tener que crear una nueva máquina virtual.
# add disk to VM
$subscription = "<yourSubscriptionID>"
$resourceGroup = "<yourResourceGroup>"
$vmName = "<yourVMName>"
$diskName = "<yourDiskName>"
$lun = 1
Login-AzureRMAccount -SubscriptionId $subscription
$vm = Get-AzVM -ResourceGroupName $resourceGroup -Name $vmName
$disk = Get-AzDisk -ResourceGroupName $resourceGroup -Name $diskName
$vm = Add-AzVMDataDisk -VM $vm -Name $diskName -CreateOption Attach -ManagedDiskId $disk.Id -Lun $lun
Ajuste del rendimiento de un disco Ultra mediante PowerShell

Los discos Ultra tienen una capacidad única que permite ajustar su rendimiento. El comando siguiente es un
ejemplo que ajusta el rendimiento sin tener que desasociar el disco:
$diskupdateconfig = New-AzDiskUpdateConfig -DiskMBpsReadWrite 2000

Update-AzDisk -ResourceGroupName $resourceGroup -DiskName $diskName -DiskUpdate $diskupdateconfig
Pasos siguientes
Si quiere probar el nuevo tipo de disco, solicite acceso con esta encuesta.
Pruebas comparativas de un disco
Las pruebas comparativas consisten en el proceso de simular cargas de trabajo diferentes en la aplicación y medir
el rendimiento de las aplicaciones para cada carga de trabajo. Mediante los pasos descritos en el artículo sobre el
diseño con alto rendimiento, recopiló los requisitos de rendimiento de las aplicaciones. Al ejecutar las
herramientas de pruebas comparativas en las máquinas virtuales en las que se hospeda la aplicación, puede
determinar los niveles de rendimiento que la aplicación puede lograr con Premium Storage. En este artículo, se
proporcionan ejemplos de pruebas comparativas realizadas con una máquina virtual estándar DS14
aprovisionada con discos de Azure Premium Storage.
Hemos usado las herramientas de pruebas comparativas comunes Iometer y FIO, para Windows y Linux
respectivamente. Estas herramientas generan varios subprocesos que simulan una carga de trabajo de producción
y miden el rendimiento del sistema. Con estas herramientas, también puede configurar parámetros como la
profundidad de la cola y el tamaño de bloque, que normalmente no se puede cambiar de una aplicación. Esto
proporciona más flexibilidad para controlar el rendimiento máximo en una máquina virtual a gran escala
aprovisionada con discos premium para diferentes tipos de cargas de trabajo de la aplicación. Para más
información sobre la herramienta de pruebas comparativas, visite Iometer y FIO.
Para seguir estos ejemplos, cree una máquina virtual estándar DS14 y conecte 11 discos de Premium Storage a la
máquina virtual. De los once discos, configure diez con almacenamiento en caché de host como "None" y
secciónelos en un volumen denominado NoCacheWrites. Configure el almacenamiento en caché de host como
"ReadOnly" en el disco restante y cree un volumen denominado CacheReads con dicho disco. Con esta
configuración, puede ver el rendimiento máximo de lectura y escritura de una máquina virtual estándar DS14.
Para obtener instrucciones detalladas sobre cómo crear una máquina virtual DS14 con SSD Premium, consulte
Azure Premium Storage: Diseño de alto rendimiento.
Preparación de la memoria caché
El disco con almacenamiento en caché de host ReadOnly puede proporcionar un valor de IOPS mayor que el
límite del disco. Para obtener este máximo rendimiento de lectura de la caché de host, primero debe preparar la
memoria caché de este disco. Así se garantiza que las operaciones de E/S de lectura en las qué la herramienta de
pruebas comparativas manejará el volumen de CacheReads alcanzan realmente la memoria caché y no el disco
directamente. Los aciertos de caché generan IOPS adicionales desde el único disco con la memoria caché
habilitada.
IMPORTANT
debe preparar la memoria caché antes de ejecutar pruebas comparativas y cada vez que se reinicie la máquina virtual.
Herramientas
Iometer
Descargue la herramienta Iometer en la máquina virtual.
Archivo de prueba
Iometer usa un archivo de prueba que se almacena en el volumen en el que se ejecuta la prueba comparativa.
Realiza lecturas y escrituras en el archivo de prueba para medir la IOPS y el rendimiento del disco. Iometer crea
este archivo de prueba si no proporcionó ninguno. Cree un archivo de prueba de 200 GB llamado iobw.tst en los
volúmenes CacheReads y NoCacheWrites.
Especificaciones de acceso
Las especificaciones, el tamaño de la E/S de las solicitudes, % de lectura o escritura, % de acceso aleatorio o
secuencial se configuran desde la pestaña "Access Specifications" (Especificaciones de acceso) de Iometer. Cree
una especificación de acceso para cada uno de los escenarios descritos a continuación. Cree las especificaciones
de acceso y "guárdelas" con un nombre apropiado como – RandomWrites_8K o RandomReads_8K. Seleccione la
especificación correspondiente al ejecutar el escenario de prueba.
A continuación se muestra un ejemplo de especificaciones de acceso para el escenario de IOPS de escritura
máxima:
Especificaciones de prueba de valor máximo de IOPS

Para demostrar el número máximo de E/S por segundo, use el tamaño de solicitud más pequeño. Use el tamaño
de solicitud de 8K y cree especificaciones de lecturas y escrituras aleatorias.
ESPECIFICACIÓN DE ACCESO TAMAÑO DE LA SOLICITUD % ALEATORIO % LECTURA
RandomWrites_8K 8K 100 0
RandomReads_8K 8K 100 100
Especificaciones de prueba de rendimiento máximo

Para demostrar el rendimiento máximo, use el tamaño de la solicitud más grande. Use el tamaño de solicitud de
64 K y cree especificaciones de lecturas y escrituras aleatorias.
ESPECIFICACIÓN DE ACCESO TAMAÑO DE LA SOLICITUD % ALEATORIO % LECTURA
RandomWrites_64K 64 K 100 0
RandomReads_64K 64 K 100 100
Ejecución de la prueba Iometer

Realice los siguientes pasos para preparar la memoria caché
1. Cree dos especificaciones de acceso con los valores que se muestran a continuación:
NOMBRE TAMAÑO DE LA SOLICITUD % ALEATORIO % LECTURA
RandomWrites_1MB 1 MB 100 0
RandomReads_1MB 1 MB 100 100
2. Ejecute la prueba Iometer para inicializar el disco de la caché con los parámetros siguientes. Use tres
subprocesos de trabajo para el volumen de destino y una profundidad de la cola de 128. Establezca la
duración del “tiempo de ejecución” de la prueba en 2 horas en la pestaña "Test Setup" (Configuración de
prueba).
ESCENARIO VOLUMEN DE DESTINO NOMBRE DURATION
Inicializar caché de disco CacheReads RandomWrites_1MB 2 horas
3. Ejecute la prueba Iometer para el preparar el disco de la caché con los parámetros siguientes. Use tres
subprocesos de trabajo para el volumen de destino y una profundidad de la cola de 128. Establezca la
duración del “tiempo de ejecución” de la prueba en 2 horas en la pestaña "Test Setup" (Configuración de
prueba).
ESCENARIO VOLUMEN DE DESTINO NOMBRE DURACIÓN
Preparación de la caché de CacheReads RandomReads_1MB 2 horas

disco
Una vez preparado el disco de memoria caché, continúe con los escenarios de prueba que se muestran a
continuación. Para ejecutar la prueba Iometer, use al menos tres subprocesos de trabajo para cada volumen de
destino. Para cada subproceso de trabajo, seleccione el volumen de destino, establezca la profundidad de la cola y
seleccione una de las especificaciones de prueba guardadas, tal como se muestra en la tabla siguiente, para
ejecutar el escenario de prueba correspondiente. La tabla también muestra los resultados esperados para IOPS y
rendimiento al ejecutar estas pruebas. Para todos los escenarios, se usa un tamaño pequeño de E/S de 8 KB y una
profundidad de la cola alta de 128.
ESCENARIO DE PRUEBA VOLUMEN DE DESTINO NOMBRE RESULTADO
Máx. IOPS de lectura CacheReads RandomWrites_8K 50.000 E/S por segundo
Máx. IOPS de escritura NoCacheWrites RandomReads_8K 64.000 IOPS
Máx. IOPS combinado CacheReads RandomWrites_8K 100.000 IOPS
NoCacheWrites RandomReads_8K
Máx. MB/s de lectura CacheReads RandomWrites_64K 524 MB/s
Máx. Escritura MB/s NoCacheWrites RandomReads_64K 524 MB/s
Combinado MB/s CacheReads RandomWrites_64K 1000 MB/s
NoCacheWrites RandomReads_64K
A continuación se muestran capturas de pantalla de los resultados de la prueba de Iometer para los escenarios
IOPS y rendimiento combinados.
Valor máximo de IOPS de lecturas y escrituras combinadas
Rendimiento máximo de lecturas y escrituras combinadas
FIO
FIO es una popular herramienta para el almacenamiento de información de referencia en las máquinas virtuales
de Linux. Tiene flexibilidad para seleccionar distintos tamaños de E/S y lecturas y escrituras secuenciales o
aleatorias. Genera subprocesos de trabajo o procesos para realizar las operaciones de E/S especificadas. Puede
especificar el tipo de operaciones de E/S que debe realizar cada subproceso de trabajo con archivos de trabajo.
Hemos creado un archivo de trabajo por escenario que se ilustra en los ejemplos siguientes. Puede cambiar las
especificaciones de estos archivos de trabajo para tener referencia de diferentes cargas de trabajo en Premium
Storage. En los ejemplos, usamos una máquina virtual estándar 14 DS que ejecuta Ubuntu. Use la misma
configuración descrita al principio de la sección Pruebas comparativas y prepare la memoria caché antes de
ejecutar dichas pruebas.
Antes de comenzar, descargue FIO e instálelo en la máquina virtual.
Ejecute el siguiente comando para Ubuntu:
apt-get install fio
Usamos cuatro subprocesos de trabajo para realizar las operaciones de escritura y cuatro subprocesos de trabajo
para realizar las operaciones de lectura en los discos. Los trabajos de escritura dirigen el tráfico del volumen
"nocache", que tiene diez discos con la memoria caché establecida en "None". Los trabajos de lectura dirigen el
tráfico del volumen "readcache", que tiene un disco con la memoria caché establecida en "ReadOnly".
Valor máximo de IOPS de escritura
Cree el archivo de trabajo con las especificaciones siguientes para obtener la IOPS de escritura máxima. Asígnele
el nombre "fiowrite.ini".
[global]
size=30g
direct=1
iodepth=256
ioengine=libaio
bs=8k
[writer1]
rw=randwrite
directory=/mnt/nocache
[writer2]
rw=randwrite
[writer3]
rw=randwrite
[writer4]
rw=randwrite
Tenga en cuenta los siguientes aspectos clave que están en consonancia con las instrucciones de diseño que se
tratan en secciones anteriores. Estas especificaciones son esenciales para alcanzar la IOPS máxima
Una profundidad de la cola alta de 256.
Un tamaño de bloque pequeño de 8 KB.
Varios subprocesos que realizan escrituras aleatorias.
Ejecute el siguiente comando para ejecutar la prueba FIO durante 30 segundos:
sudo fio --runtime 30 fiowrite.ini
Mientras se ejecuta la prueba, puede ver el número de IOPS de escritura que envían la máquina virtual y los
discos Premium. Como se muestra en el ejemplo siguiente, la máquina virtual DS14 está ofreciendo su límite
máximo de IOPS de escritura: 50.000 IOPS.
Valor máximo de IOPS de lectura
Cree el archivo de trabajo con las especificaciones siguientes para obtener la IOPS de lectura máxima. Asígnele el
nombre "fioread.ini".
[global]
size=30g
direct=1
iodepth=256
ioengine=libaio
bs=8k
[reader1]
rw=randread
directory=/mnt/readcache
[reader2]
rw=randread
[reader3]
rw=randread
[reader4]
rw=randread
Varios subprocesos que realizan escrituras aleatorias.
sudo fio --runtime 30 fioread.ini
Mientras se ejecuta la prueba, puede ver el número de IOPS de lectura que envían los discos Premium y de VM.
Como se muestra en el ejemplo siguiente, la máquina virtual DS14 proporciona más de 64.000 IOPS de lectura.
Se trata de una combinación del rendimiento de la caché y el disco.
Valor máximo de IOPS de lectura y escritura

Cree el archivo de trabajo con las especificaciones siguientes para obtener la IOPS de lectura y escritura
combinadas máxima. Asígnele el nombre "fioreadwrite.ini".
[global]
size=30g
direct=1
iodepth=128
ioengine=libaio
bs=4k
[reader1]
rw=randread
[reader2]
rw=randread
[reader3]
rw=randread
[reader4]
rw=randread
[writer1]
rw=randwrite
rate_iops=12500
[writer2]
rw=randwrite
rate_iops=12500
[writer3]
rw=randwrite
rate_iops=12500
[writer4]
rw=randwrite
rate_iops=12500
Varios subprocesos que realizan lecturas y escrituras aleatorias.
sudo fio --runtime 30 fioreadwrite.ini
Mientras se ejecuta la prueba, puede ver el número de IOPS de lectura y escritura combinadas que envían la
máquina virtual y los discos Premium. Como se muestra en el ejemplo siguiente, la máquina virtual DS14
proporciona más de 100.000 IOPS de lectura y escritura combinadas. Se trata de una combinación del
rendimiento de la caché y el disco.
Rendimiento máximo combinado

Para obtener el rendimiento de lectura y escritura combinado máximo, use un tamaño de bloque y la profundidad
de la cola más grandes con varios subprocesos que realizan lecturas y escrituras. Puede usar un tamaño de bloque
de 64 KB y una profundidad de la cola de 128.
Pasos siguientes
Continúe con nuestro artículo sobre el diseño para lograr un alto rendimiento. En dicho artículo, se crea una lista
de comprobación similar a la aplicación existente para el prototipo. Con herramientas de pruebas comparativas
puede simular las cargas de trabajo y medir el rendimiento de las aplicaciones de prototipo. De este modo, puede
determinar qué oferta de disco puede alcanzar o superar los requisitos de rendimiento de las aplicaciones. A
continuación, puede implementar las mismas directrices para la aplicación de producción.
Consulte el artículo sobre el diseño para lograr un alto rendimiento.
Búsqueda y eliminación de discos administrados y no
administrados de Azure no conectados
Cuando se elimina una máquina virtual (VM ) en Azure, de forma predeterminada, no se elimina ningún disco
asociado a la máquina virtual. Esta característica ayuda a evitar la pérdida de datos debido a la eliminación
accidental de máquinas virtuales. Después de eliminar una máquina virtual, seguirá pagando por los discos no
asociados. En este artículo se muestra cómo buscar y eliminar los discos no asociados y reducir costos
innecesarios.
Discos administrados: Búsqueda y eliminación de discos no conectados

El siguiente script busca los discos administrados no asociados examinando el valor de la propiedad ManagedBy.
Cuando un disco administrado está asociado a una máquina virtual, la propiedad ManagedBy contiene el
identificador de recurso de la máquina virtual. Cuando se desasocia, le propiedad ManagedBy tiene un valor null.
El script examina todos los discos administrados de una suscripción de Azure. Cuando el script localiza un disco
administrad con la propiedad ManagedBy establecida en null, se determina que el disco no está asociado.
IMPORTANT
Primero, ejecute el script y establezca la variable deleteUnattachedDisks en 0. Esta acción le permite buscar y ver todos los
discos administrados no asociados.
Después de revisar todos los discos no asociados, vuelva a ejecutar el script y establezca la variable deleteUnattachedDisks
en 1. Esta acción le permite eliminar todos los discos administrados no asociados.
# Set deleteUnattachedDisks=1 if you want to delete unattached Managed Disks

# Set deleteUnattachedDisks=0 if you want to see the Id of the unattached Managed Disks
$deleteUnattachedDisks=0
$managedDisks = Get-AzDisk
foreach ($md in $managedDisks) {
# ManagedBy property stores the Id of the VM to which Managed Disk is attached to
# If ManagedBy property is $null then it means that the Managed Disk is not attached to a VM
if($md.ManagedBy -eq $null){
if($deleteUnattachedDisks -eq 1){
Write-Host "Deleting unattached Managed Disk with Id: $($md.Id)"
$md | Remove-AzDisk -Force
Write-Host "Deleted unattached Managed Disk with Id: $($md.Id) "
}else{
$md.Id
}
}
}
Discos no administrados: Búsqueda y eliminación de discos no

conectados
Los discos no administrados son archivos VHD almacenados como blobs en páginas en cuentas de Azure Storage.
El siguiente script busca discos no administrados no asociados (blobs en páginas) examinando el valor de la
propiedad LeaseStatus. Cuando un disco no administrado está asociado a una máquina virtual, la propiedad
LeaseStatus se establece en Bloqueado. Cuando un disco no administrado está desasociado, la propiedad
LeaseStatus se establece en Desbloqueado. El script examina todos los discos no administrados de todas las
cuentas de almacenamiento de Azure de una suscripción de Azure. Cuando el script localiza un disco no
administrado con la propiedad LeaseStatus establecida en Desbloqueado, se determina que el disco no está
asociado.
IMPORTANT
Primero, ejecute el script y establezca la variable deleteUnattachedVHDs en 0. Esta acción le permite buscar y ver todos los
discos duros virtuales no administrados y no asociados.
Después de revisar todos los discos no asociados, vuelva a ejecutar el script y establezca la variable deleteUnattachedVHDs
en 1. Esta acción le permite eliminar todos los discos duros virtuales no administrados y no asociados.
# Set deleteUnattachedVHDs=1 if you want to delete unattached VHDs

# Set deleteUnattachedVHDs=0 if you want to see the Uri of the unattached VHDs
$deleteUnattachedVHDs=0
$storageAccounts = Get-AzStorageAccount
foreach($storageAccount in $storageAccounts){
$storageKey = (Get-AzStorageAccountKey -ResourceGroupName $storageAccount.ResourceGroupName -Name
$storageAccount.StorageAccountName)[0].Value
$context = New-AzStorageContext -StorageAccountName $storageAccount.StorageAccountName -StorageAccountKey
$storageKey
$containers = Get-AzStorageContainer -Context $context
foreach($container in $containers){
$blobs = Get-AzStorageBlob -Container $container.Name -Context $context
#Fetch all the Page blobs with extension .vhd as only Page blobs can be attached as disk to Azure VMs
$blobs | Where-Object {$_.BlobType -eq 'PageBlob' -and $_.Name.EndsWith('.vhd')} | ForEach-Object {
#If a Page blob is not attached as disk then LeaseStatus will be unlocked
if($_.ICloudBlob.Properties.LeaseStatus -eq 'Unlocked'){
if($deleteUnattachedVHDs -eq 1){
Write-Host "Deleting unattached VHD with Uri: $($_.ICloudBlob.Uri.AbsoluteUri)"
$_ | Remove-AzStorageBlob -Force
Write-Host "Deleted unattached VHD with Uri: $($_.ICloudBlob.Uri.AbsoluteUri)"
}
else{
$_.ICloudBlob.Uri.AbsoluteUri
}
}
}
}
}
Pasos siguientes
Para más información, consulte Eliminar una cuenta de almacenamiento e Identify Orphaned Disks Using
PowerShell (Identificación de discos huérfanos con PowerShell).
Inicio rápido: Creación y administración de un recurso
compartido de Azure Files con Windows Virtual
Machines
El artículo muestra los pasos básicos para crear y usar un recurso compartido de Azure Files. Este inicio rápido se
centra en la configuración rápida de un recurso compartido de Azure Files para experimentar el funcionamiento
del servicio. Si necesita instrucciones más detalladas para crear y usar recursos compartidos de archivos de Azure
en su propio entorno, consulte Uso de un recurso compartido de archivos de Azure con Windows.

Preparación del entorno

En este inicio rápido, configurará los elementos siguientes:
Una cuenta de Azure Storage y un recurso compartido de archivos de Azure
Una máquina virtual Windows Server 2016 Datacenter
Crear una cuenta de almacenamiento
Para poder trabajar con un recurso compartido de archivos de Azure, es necesario que cree una cuenta de Azure
Storage. Una cuenta de almacenamiento v2 de uso general proporciona acceso a todos los servicios de Azure
Storage: Blob, File, Queue y Table. El inicio rápido crea una cuenta de almacenamiento de uso general v2, pero los
pasos para crear cualquier otro tipo de cuenta de almacenamiento son similares. Una cuenta de almacenamiento
puede contener un número ilimitado de recursos compartidos. Un recurso compartido puede almacenar un
número ilimitado de archivos, hasta los límites de capacidad de la cuenta de almacenamiento.
Para crear una cuenta de almacenamiento de uso general v2 en Azure Portal, siga estos pasos:
1. En Azure Portal, seleccione Todos los servicios. En la lista de recursos, escriba Cuentas de
almacenamiento. Cuando comience a escribir, la lista se filtrará en función de la entrada. Seleccione
Cuentas de almacenamiento.
2. En la ventana Cuentas de almacenamiento que aparece, elija Agregar.
3. Seleccione la suscripción en la que se va a crear la cuenta de almacenamiento.
4. En el campo Grupo de recursos, haga clic en Crear nuevo. Escriba un nombre para el nuevo grupo de
recursos, como se muestra en la siguiente imagen.
5. Después, escriba un nombre para la cuenta de almacenamiento. El nombre que elija debe ser único en
Azure. El nombre debe tener también una longitud de entre 3 y 24 caracteres y solo puede contener
números y letras minúsculas.
6. Seleccione una ubicación para la cuenta de almacenamiento o utilice la ubicación predeterminada.
7. Deje estos campos con sus valores predeterminados:
CAMPO VALOR
Modelo de implementación Resource Manager
Rendimiento Estándar
Tipo de cuenta StorageV2 (uso general v2)
Replicación Almacenamiento con redundancia geográfica con acceso

de lectura (RA-GRS).
Nivel de acceso Acceso frecuente

8. Seleccione Revisar y crear para revisar la configuración de la cuenta de almacenamiento y crear la cuenta.
Para obtener más información sobre los tipos de cuentas de almacenamiento y otros parámetros de la cuenta de
almacenamiento, consulte Introducción a las cuentas de Azure Storage. Para más información sobre los grupos de
recursos, consulte Información general de Azure Resource Manager.
Creación de un recurso compartido de archivos de Azure
A continuación creará un recurso compartido de archivos.
1. Cuando se complete la implementación de la cuenta de Azure Storage, seleccione Ir al recurso.
2. Seleccione Archivos en el panel de la cuenta de almacenamiento.
3. Seleccione Recurso compartido de archivos.
4. Dele al nuevo recurso compartido el nombre qsfileshare > escriba "1" para Cuota > seleccione Crear. El
valor máximo de la cuota es 5 TiB, pero para esta guía de inicio rápido solo se necesita 1 GiB.
5. Cree un nuevo archivo txt denominado qsTestFile en la máquina local.
6. Seleccione el nuevo recurso compartido de archivos y en su ubicación, haga clic en Cargar.
7. Vaya a la ubicación donde creó el archivo .txt > seleccione qsTestFile.txt > seleccione Cargar.
Ya ha creado una cuenta de Azure Storage y un recurso compartido de archivos con un solo archivo en Azure.
Ahora creará la máquina virtual de Azure con Windows Server 2016 Datacenter para representar el servidor local
en esta guía de inicio rápido.
Implementación de una máquina virtual
1. A continuación, expanda el menú del lado izquierdo del portal y elija Crear un recurso en la esquina
superior izquierda de Azure Portal.
2. En el cuadro de búsqueda que está encima de la lista de recursos de Azure Marketplace, busque
Windows Server 2016 Datacenter, selecciónelo y, después, elija Crear.
3. En la pestaña Conceptos básicos, en Detalles del proyecto, seleccione el grupo de recursos que creó
para esta guía de inicio rápido.
4. En Detalles de la instancia, asigne a la máquina virtual el nombre qsVM.

5. Deje la configuración predeterminada en Región, Opciones de disponibilidad, Imagen y Tamaño.
6. En Cuenta de administrador, agregue VMadmin como el Nombre de usuario y escriba una Contraseña
para la máquina virtual.
7. En Reglas de puerto de entrada, elija Permitir los puertos seleccionados y luego seleccione RDP
(3389) y HTTP en la lista desplegable.
8. Seleccione Revisar + crear.
9. Seleccione Crear. La creación de una máquina virtual nueva tardará varios minutos en completarse.
10. Después de completar la implementación de la máquina virtual, seleccione Ir al recurso.
Ya ha creado una nueva máquina virtual y ha conectado un disco de datos. Ahora tiene que conectarse a la
máquina virtual.
1. Seleccione Conectar en la página de propiedades de la máquina virtual.
2. En la página Connect to virtual machine (Conectarse a una máquina virtual), mantenga las opciones
predeterminadas para conectarse por dirección IP a través del número de puerto 3389 y seleccione
Descargar archivo RDP.
4. En la ventana Seguridad de Windows, seleccione Más opciones y, después, Usar otra cuenta. Escriba el
nombre de usuario con el siguiente formato, localhost\nombre de usuario, siendo <nombre de usuario> el
nombre de usuario administrador de la máquina virtual que creó. Escriba la contraseña que creó para la
máquina virtual y, luego seleccione Aceptar.
5. Puede recibir una advertencia de certificado durante el proceso de inicio de sesión. Seleccione Sí o
Asigne el recurso compartido de archivos de Azure a una unidad de

Windows
1. En Azure Portal, vaya al recurso compartido de archivos qsfileshare y seleccione Conectar.
2. Copie el contenido de la segunda casilla y péguelo en el Bloc de notas.
3. En la máquina virtual, abra Explorador de archivos y seleccione Este equipo en la ventana. Esta selección
cambiará los menús disponibles en la barra de herramientas. En el menú Equipo, seleccione Conectar a
unidad de red.
4. Seleccione la letra de unidad y escriba la ruta de acceso UNC. Si ha seguido las sugerencias de
nomenclatura en esta guía de inicio rápido, copie \qsstorageacct.file.core.windows.net\qsfileshare desde el
Bloc de notas.
Asegúrese de que ambas casillas están seleccionadas.
5. Seleccione Finalizar.
6. En el cuadro de diálogo Seguridad de Windows:
Desde el Bloc de notas, copie el nombre de la cuenta de almacenamiento precedido de AZURE\ y
péguelo en el cuadro de diálogo Windows Security como nombre de usuario. Si ha seguido las
sugerencias de nomenclatura en esta guía de inicio rápido, copie AZURE\qsstorageacct.
Desde el Bloc de notas, copie la clave de la cuenta de almacenamiento y péguela en el cuadro de
diálogo Windows Security como contraseña.
Creación de una instantánea de recurso compartido

Ahora que ha asignado la unidad, puede crear una instantánea.
1. En el portal, vaya al recurso compartido de archivos y seleccione Crear instantánea.
2. En la máquina virtual, abra qstestfile.txt y escriba "este archivo se ha modificado" > Guarde y cierre el
archivo.
3. Cree otra instantánea.
Búsqueda de una instantánea de recurso compartido

1. En el recurso compartido de archivos, seleccione Ver instantáneas.
2. En el panel Instantáneas de recursos compartidos de archivos, seleccione la primera instantánea en la
lista.
3. En el panel de esa instantánea, seleccione qsTestFile.txt.
Restauración desde una instantánea

1. En la hoja de instantánea de recurso compartido de archivo, haga clic con el botón derecho en qsTestFile y
seleccione el botón Restaurar.
2. Seleccione Sobrescribir el archivo original.
3. En la máquina virtual, abra el archivo. Se ha restaurado la versión no modificada.
Eliminación de una instantánea de recurso compartido

1. En el recurso compartido de archivos, seleccione Ver instantáneas.
2. En el panel Instantáneas de recursos compartidos de archivos, seleccione las últimas instantáneas en la
lista y haga clic en Eliminar.
Uso de una instantánea de recurso compartido en Windows
Al igual que con las instantáneas VSS en el entorno local, puede ver las instantáneas desde el recurso compartido
de archivos de Azure montado en la pestaña Versiones anteriores.
1. Ubique el recurso compartido montado en el Explorador de archivos.
2. Seleccione qsTestFile.txt > haga clic con el botón derecho y seleccione Propiedades en el menú.
3. Seleccione Versiones anteriores para ver la lista de instantáneas de recursos compartidos de este
directorio.
4. Seleccione Abrir para abrir el archivo.
Restaurar desde una versión anterior
1. Seleccione Restaurar. Esta acción copia el contenido de todo un directorio de forma recursiva en la
ubicación original en el momento de la creación de la instantánea del recurso compartido.
Cuando haya terminado, puede eliminar el grupo de recursos. Al eliminar el grupo de recursos, se elimina la cuenta
de almacenamiento, el recurso compartido de archivos de Azure y otros recursos que se implementaron en el
grupo de recursos.
1. En el menú de la izquierda, seleccione Grupos de recursos.
2. Haga clic con el botón derecho en el grupo de recursos y seleccione Eliminar grupo de recursos. Se abre una
ventana con una advertencia acerca de los recursos que se eliminarán con el grupo de recursos.
3. Escriba el nombre del grupo de recursos y, luego, seleccione Eliminar.
Pasos siguientes
Uso de un recurso compartido de archivos de Azure con Windows
Preguntas más frecuentes sobre los discos de
máquina virtual de IaaS de Azure y los discos
premium administrados y no administrados
En este artículo se responden algunas de las preguntas más frecuentes acerca de Azure Managed Disks y los
discos SSD Premium de Azure.
Managed Disks
¿Qué es Azure Managed Disks?
Managed Disks es una característica que simplifica la administración de discos para máquinas virtuales de IaaS de
Azure al controlar automáticamente la administración de la cuenta de almacenamiento. Para obtener más
información, consulte Introducción a Azure Managed Disks.
Si creo un disco administrado estándar a partir un disco duro virtual existente con 80 GB de tamaño,
¿cuánto me costará?
Un disco administrado estándar creado a partir de un disco duro virtual de 80 GB se trata como el siguiente
tamaño de disco estándar disponible, es decir, un disco S10. Se le cobrará según el precio de disco S10. Consulte
la página de preciospara obtener más información.
¿Existen costes de transacción para los discos administrados estándar?
Sí. Sí, se le cobrará por cada transacción. Consulte la página de preciospara obtener más información.
Para un disco administrado estándar, ¿se me cobrará por el tamaño real de los datos en el disco o la
capacidad aprovisionada del disco?
Se le cobra en función de la capacidad aprovisionada del disco. Consulte la página de preciospara obtener más
información.
¿En qué se diferencian los precios de los discos administrados premium de los de los discos no
administrados?
Los precios de los discos administrados premium son iguales que los de los discos no administrados premium.
¿Puedo cambiar el tipo de cuenta de almacenamiento (Estándar o Premium ) de mis discos
administrados?
Sí. Puede cambiar el tipo de cuenta de almacenamiento de los discos administrados mediante Azure Portal,
PowerShell o la CLI de Azure.
¿Puedo usar un archivo de disco duro virtual en una cuenta de Azure Storage para crear un disco
administrado con una suscripción distinta?
Sí.
¿Puedo usar un archivo de disco duro virtual en una cuenta de Azure Storage para crear un disco
administrado en una región diferente?
No.
¿Hay alguna limitación de escala para los clientes que usen discos administrados?
Managed Disks elimina los límites asociados a las cuentas de almacenamiento. Sin embargo, el límite máximo es
de 50 000 discos administrados por región y por tipo de disco para una suscripción.
¿Puedo tomar una instantánea incremental de un disco administrado?
No. La funcionalidad de instantánea actual realiza una copia completa de un disco administrado.
¿Pueden las máquinas virtuales de un conjunto de disponibilidad estar compuestas de una
combinación de discos administrados y no administrados?
No. Las máquinas virtuales de un conjunto de disponibilidad deben utilizar únicamente discos administrados o no
administrados. Cuando cree un conjunto de disponibilidad, puede elegir qué tipo de discos desea usar.
¿Es Managed Disks la opción predeterminada en Azure Portal?
Sí.
¿Puedo crear un disco administrado vacío?
Sí. Puede crear un disco vacío. Un disco administrado se puede crear de forma independiente de una máquina
virtual, por ejemplo, sin conectarlo a una máquina virtual.
¿Qué número de dominios de error se admite para un conjunto de disponibilidad que use Managed
Disks?
En función de la región en la que se encuentre el conjunto de disponibilidad que use Managed Disks, el número de
dominios de error admitidos es de 2 o 3.
¿Cómo se configura una cuenta de almacenamiento estándar para el diagnóstico?
Se configura una cuenta de almacenamiento privada para el diagnóstico de máquinas virtuales.

¿Qué tipo de compatibilidad con el Control de acceso basado en roles está disponible para Managed
Disks?
Managed Disks admite tres roles predeterminados fundamentales:
Propietario: Puede administrar todo el contenido, incluido el acceso
Colaborador: Puede administrar todo el contenido, excepto el acceso
Lector: Puede ver todo el contenido, pero no puede realizar cambios
¿Hay alguna manera de copiar o exportar un disco administrado a una cuenta de almacenamiento
privada?
Puede generar un identificador URI de firma de acceso compartido (SAS ) de solo lectura para el disco
administrado y usarlo para copiar el contenido a una cuenta de almacenamiento privada o al almacenamiento
local. Puede usar el identificador URI de SAS con Azure Portal, Azure PowerShell, la CLI de Azure o AzCopy.
¿Puedo crear una copia de mi disco administrado?
Los clientes pueden crear una instantánea de sus discos administrados y usarla para crear otro disco administrado.
¿Siguen siendo compatibles los discos no administrados?
Sí, se admiten discos administrados y no administrados. Recomendamos que empiece a usar discos administrados
para las cargas de trabajo nuevas y migre las cargas de trabajo actuales a discos administrados.
¿Puedo localizar conjuntamente discos administrados y no administrados en la misma máquina virtual?
No.
Si creo un disco de 128 GB y después aumento el tamaño a 130 gibibytes (GiB ), ¿se me cobra por el
siguiente tamaño de disco (256 GiB )?
Sí.
¿Puedo crear discos administrados para el almacenamiento con redundancia local, almacenamiento
con redundancia geográfica y almacenamiento con redundancia de zona?
Actualmente, Azure Managed Disks solo admite discos administrados de almacenamiento con redundancia local.
¿Puedo reducir mis discos administrados?
No. En la actualidad no se admite esta característica.

¿Se puede interrumpir una concesión en el disco?
No. Esto no es posible actualmente, ya que la concesión está presente para evitar una eliminación accidental
cuando se está utilizando el disco.
¿Se puede cambiar la propiedad de nombre de equipo cuando se usa un disco de sistema operativo
especializado (no creado mediante la herramienta de preparación del sistema o generalizado) para
aprovisionar una máquina virtual?
No. No se puede actualizar la propiedad de nombre de equipo. La nueva máquina virtual lo hereda de la máquina
virtual principal que se usó para crear el disco del sistema operativo.
¿Dónde puedo encontrar plantillas de Azure Resource Manager de ejemplo para crear máquinas
virtuales con discos administrados
Lista de plantillas mediante discos administrados
https://github.com/chagarw/MDPP
Al crear un disco desde un blob, ¿hay alguna relación continuamente existente con ese blob de origen?
No, cuando se crea el nuevo disco es una copia completa independiente de ese blob en ese momento y no hay
ninguna conexión entre los dos. Si lo desea, una vez que haya creado el disco, puede eliminar el blob de origen sin
afectar al disco recién creado en modo alguno.
¿Se puede cambiar el nombre de un disco administrado o no administrado después de haberlo creado?
No se puede cambiar el nombre de los discos administrados. Sin embargo, es posible cambiar el nombre de un
disco no administrado; siempre y cuando no esté asociado a una VM o a un disco duro virtual.
¿Puedo usar la creación de particiones de GPT en un disco de Azure?
La creación de particiones de GPT solo se puede usar en discos de datos, no en discos de sistemas operativos. Los
discos de SO deben usar el estilo de partición de MBR.
¿Qué tipos de discos admiten instantáneas?
SSD Premium, SSD estándar y HDD estándar admiten instantáneas. En estos tres tipos de discos, las instantáneas
se admiten en todos los tamaños de disco (incluidos los discos de hasta 32 TiB ). Los discos Ultra no admiten
instantáneas.
Reserva de discos
¿Qué es la reserva de discos de Azure? La reserva de discos es la opción de adquirir de antemano un año de
almacenamiento en discos, lo que reduce los costos totales.
¿Qué opciones ofrece la reserva de discos de Azure? La reserva de discos de Azure ofrece la opción de
comprar SSD Premium en las SKU especificadas de P30 (1 TiB ) hasta P80 (32 TiB ) durante un año. No hay
ninguna limitación en la cantidad mínima de discos necesarios para comprar una reserva de discos. Además,
puede pagar realizando un solo pago inicial o mediante pagos mensuales. No hay ningún costo transaccional
adicional aplicado en Managed Disks de SSD Premium.
Las reservas se realizan en forma de discos y no de capacidad. En otras palabras, cuando se reserva un disco de
P80 (32 TiB ), se obtiene un solo disco de P80, no se puede dividir esa reserva específica en dos discos de P70 más
pequeños (16 TiB ). Por supuesto, puede reservar el número de discos que quiera, incluidos dos discos de P70
independientes (16 TiB ).
¿Cómo se me cobrará la reserva de discos de Azure?
Los clientes con Contrato Enterprise (EA) pueden usar primero el compromiso monetario de Azure para
comprar reservas de discos de Azure. Además, aunque los clientes con Contrato Enterprise hayan usado
todo su compromiso monetario, pueden comprar reservas de discos, y el importe correspondiente se
cobrará en la próxima factura de uso por encima del límite.
En cuanto a los clientes que compren a través de Azure.com, se cargará a la tarjeta de crédito registrada el
pago inicial completo (o los pagos fijos mensuales) de la reserva de discos de Azure en el momento de la
compra.
¿Cómo se aplica la reserva de discos de Azure? La reserva de discos sigue un modelo similar a las instancias
reservadas de máquina virtual (VM ). La diferencia es que una reserva de discos no se puede aplicar a diferentes
SKU, mientras que una instancia de VM sí puede. Consulte Ahorro de costos con Azure Reserved VM Instances
para obtener más información sobre las instancias de VM.
¿Puedo usar mi almacenamiento de datos adquirido a través de la reserva de discos de Azure en varias
regiones? La reserva de discos de Azure se compra para una región específica y una SKU (como P30 en el Este
de EE. UU. 2) y, por lo tanto, no se puede usar fuera de estas áreas. Siempre puede adquirir una reserva de discos
de Azure adicional en función de las necesidades de almacenamiento en disco que tenga en otras regiones o SKU.
¿Qué ocurre cuando expira la reserva de discos Azure? Recibirá notificaciones por correo electrónico 30 días
antes de la expiración y también en la fecha de expiración. Una vez que expire la reserva, los discos implementadas
seguirán ejecutándose y se facturarán mediante una cuota de pago por uso.
Discos Ultra
¿Qué rendimiento del disco Ultra se debe establecer? Si no está seguro de qué rendimiento de disco
establecer, se recomienda que comience asumiendo un tamaño de E/S de 16 KiB y ajuste el rendimiento a partir
de ahí mientras supervisa la aplicación. La fórmula es: Rendimiento en MBps = n.º de IOPS * 16/1000.
He configurado el disco en 40 000 IOPS pero solo veo 12 800 IOPS, ¿por qué no veo el rendimiento del
disco? Además de la limitación del disco, existe una limitación de E/S que se impone a nivel de máquina virtual.
Asegúrese de que el tamaño de máquina virtual que está usando puede admitir los niveles que están configurados
en los discos. Para más información sobre los límites de E/S impuestos por la máquina virtual, consulte Tamaños
de las máquinas virtuales Windows en Azure.
¿Puedo usar niveles de almacenamiento en caché con un disco Ultra? No, los discos Ultra no admiten los
distintos métodos de almacenamiento en caché que se admiten en otros tipos de discos. Establezca el
almacenamiento en caché de disco en Ninguno.
¿Puedo conectar un disco Ultra a mi máquina virtual actual? Es posible. La máquina virtual debe
encontrarse en un par de región y zona de disponibilidad que admita discos Ultra. Consulte Introducción a los
discos Ultra para más información.
¿Puedo usar un disco Ultra como disco del sistema operativo para mi máquina virtual? No, los discos
Ultra solo se admiten como discos de datos y solo se admiten como discos nativos de 4K.
¿Puedo convertir un disco existente en un disco Ultra? No, pero puede migrar los datos de un disco existente
a un disco Ultra. Para migrar un disco existente a un disco Ultra, conecte ambos discos a la misma máquina virtual
y copie los datos de un disco al otro o utilice una solución de terceros para migrar los datos.
¿Se pueden crear instantáneas de discos Ultra? No, las instantáneas no están disponibles todavía.
¿Está Azure Backup disponible para discos Ultra? No, la compatibilidad con Azure Backup aún no está
disponible.
¿Puedo conectar un disco Ultra a una máquina virtual que se ejecuta en un conjunto de disponibilidad?
No, esto aún no es posible.
¿Puedo habilitar Azure Site Recovery para máquinas virtuales que usan discos Ultra? No, Azure Site
Recovery todavía no es compatible con discos Ultra.
Carga en un disco administrado

¿Puedo cargar datos en un disco administrado existente?
No, la carga solo se puede usar durante la creación de un nuevo disco vacío con el estado ReadyToUpload.
¿Cómo se carga en un disco administrado?
Cree un disco administrado con la propiedad createOption de creationData establecida en "Upload" y, después,
puede cargar datos en él.
¿Puedo conectar un disco a una máquina virtual mientras se encuentra en un estado de carga?
No.
¿Se puede tomar una instantánea de un disco administrado en un estado de carga?
No.
Discos SSD estándar

¿Qué son los discos SSD estándar de Azure? Los discos SSD estándar son discos estándar respaldados por
soportes físicos, optimizados como solución de almacenamiento rentable para cargas de trabajo que necesitan un
rendimiento constante en niveles inferiores de IOPS.
¿Cuáles son las regiones que se admiten actualmente para los discos SSD estándar? Todas las regiones de
Azure ahora admiten discos SSD estándar.
¿Azure Backup está disponible al usar SSD estándar? Sí, Azure Backup ya está disponible.
¿Cómo creo discos SSD estándar? Puede crear discos SSD estándar mediante plantillas de Azure Resource
Manager, el SDK, PowerShell o la CLI. A continuación se muestran los parámetros necesarios de la plantilla de
Resource Manager para crear discos SSD estándar:
La apiVersion para Microsoft.Compute se debe establecer en 2018-04-01 (o posterior)
Especifique managedDisk.storageAccountType como StandardSSD_LRS
El siguiente ejemplo muestra la sección properties.storageProfile.osDisk de una máquina virtual que usa un disco
SSD estándar:
"osDisk": {
"name": "myOsDisk",
"managedDisk": {
"storageAccountType": "StandardSSD_LRS"
}
}
Para obtener un ejemplo de plantilla completa de cómo crear un disco SSD estándar con una plantilla, consulte
Create a VM from a Windows Image with Standard SSD Data Disks (Creación de una máquina virtual a partir de
una imagen de Windows con discos de datos SSD estándar).
¿Puedo convertir mis discos existentes a SSD estándar? Sí, puede hacerlo. Consulte Conversión de
almacenamiento de Azure Managed Disks de estándar a premium, y viceversa para conocer las directrices
generales de la conversión de Managed Disks. Y utilice el siguiente valor para actualizar el tipo de disco a SSD
estándar. -AccountType StandardSSD_LRS
¿Cuál es la ventaja de utilizar discos SSD estándar en lugar de unidades de disco duro? Los discos SSD
estándar ofrecen una mejor latencia, coherencia, disponibilidad y confiabilidad en comparación con los discos
HDD. Debido a esto, las cargas de trabajo de las aplicaciones se ejecutan mucho mejor. Tenga en cuenta que los
discos SSD Premium son la solución recomendada para la mayoría de las cargas de trabajo producción con uso
intensivo de E/S.
¿Puedo usar discos SSD estándar como discos no administrados? No, los discos SSD estándar solo están
disponibles como discos administrados.
¿Los discos SSD estándar admiten "Acuerdo de Nivel de Servicio de máquina virtual de instancia
única"? No, los discos SSD estándar no tiene un Acuerdo de Nivel de Servicio de máquina virtual de instancia
única. Use discos SSD Premium para tener ese acuerdo.
Migración a Managed Disks

¿Hay algún impacto de la migración en el rendimiento de Managed Disks?
La migración conlleva el traslado del disco de una ubicación de almacenamiento a otra. Esto se orquesta mediante
una copia en segundo plano de los datos que puede tardar varias horas en completarse, normalmente menos de
24 horas en función de la cantidad de datos en los discos. Durante ese tiempo, la aplicación puede experimentar
una latencia de lectura más alta de lo habitual, ya que algunas lecturas pueden redirigirse a la ubicación original y
pueden tardar más tiempo en completarse. No hay ningún impacto en la latencia de escritura durante este
período.
¿Qué cambios son necesarios en una configuración del servicio Azure Backup preexistente antes y
después de la migración a Managed Disks?
No es preciso realizar cambios.
¿Las copias de seguridad de mi máquina virtual creadas con el servicio Azure Backup antes de la
migración seguirán funcionando?
Sí, las copias de seguridad funcionan sin problemas.
¿Qué cambios son necesarios en una configuración de Azure Disks Encryption ya existente antes y
después de la migración a Managed Disks?
No es preciso realizar cambios.
¿Se admite la migración automática de un conjunto de escalado de máquinas virtuales existente de
discos no administrados a Managed Disks?
No. Puede crear un nuevo conjunto de escalado con Managed Disks con la imagen del antiguo conjunto de
escalado con discos no administrados.
¿Puedo crear un disco administrado desde una instantánea de blob en páginas tomada antes de migrar
a Managed Disks?
No. Puede exportar una instantánea del blob en páginas como un blob en páginas y, a continuación, crear un disco
administrado a partir del blob en páginas exportado.
¿Se puede realizar una conmutación por error de mis equipos locales protegidos por Azure Site
Recovery a una máquina virtual con Managed Disks?
Sí, puede realizar la conmutación por error a una máquina virtual con Managed Disks.
¿Hay algún impacto en la migración de las máquinas virtuales de Azure protegidas por Azure Site
Recovery mediante la replicación de Azure a Azure?
No. Está disponible la protección de Azure a Azure de Azure Site Recovery para máquinas virtuales con Managed
Disks.
¿Puedo migrar máquinas virtuales con discos no administrados que se encuentran en las cuentas de
almacenamiento que se hayan cifrado previamente en discos administrados?
Sí
Managed Disks y Storage Service Encryption

¿Está habilitado el servicio Storage Service Encryption de forma predeterminada al crear un disco
administrado?
Sí.
¿El volumen de arranque está cifrado de forma predeterminada en un disco administrado?
Sí. De forma predeterminada, se cifran todos los discos administrados, incluido el disco del sistema operativo.
¿Quién administra las claves de cifrado?
Microsoft administra las claves de cifrado.

¿Puedo deshabilitar Storage Service Encryption para Managed Disks?
No.
¿Storage Service Encryption está solo disponible en determinadas regiones?
No. Está en todas las regiones donde esté disponible Managed Disks. Managed Disks está disponible en todas las
regiones públicas y Alemania. También está disponible en China, sin embargo, solo para las claves administradas
por Microsoft, no para las claves administradas por el cliente.
¿Cómo averiguo si mi disco administrado está cifrado?
Puede averiguar la hora de creación de un disco administrado desde Azure Portal, la CLI de Azure y PowerShell. Si
la hora es posterior al 9 de junio de 2017, el disco está cifrado.
¿Cómo puedo cifrar mis discos existentes que se crearon antes del 10 de junio de 2017?
A partir del 10 de junio de 2017 los nuevos datos escritos en los discos administrados existentes se cifran
automáticamente. También tenemos previsto cifrar los datos existentes y el cifrado se realizará de forma
asincrónica en segundo plano. Si debe cifrar ahora los datos existentes, cree una copia del disco. Los discos nuevos
se cifrarán.
Copia de discos administrados mediante la CLI de Azure
Copia de discos administrados mediante PowerShell
¿Están cifradas las imágenes e instantáneas administradas?
Sí. Todas las instantáneas e imágenes administradas creadas después del 9 de junio de 2017 se cifran
automáticamente.
¿Puedo convertir máquinas virtuales con discos no administrados que se encuentran en las cuentas de
almacenamiento o que se hayan cifrado previamente en discos administrados?
Sí
¿Se cifrará también un VHD exportado de un disco administrado o de una instantánea?
No. Pero si exporta un disco duro virtual a una cuenta de almacenamiento cifrada desde un disco administrado
cifrado o una instantánea, en este caso se cifra.
Discos premium: Administrados y no administrados

Si una máquina virtual usa una serie de tamaño que admite discos SSD premium, como DSv2, ¿puedo
conectar discos de datos tanto premium como estándar?
Sí.
¿Puedo conectar discos de datos tanto premium como estándar a una serie de tamaño que no admita
discos SSD premium, por ejemplo, las series D, Dv2, G o F?
No. Solo puede conectar discos de datos estándar a máquinas virtuales que no utilicen una serie de tamaño que
admita discos SSD premium.
Si creo un disco de datos premium a partir un disco duro virtual existente con 80 GB, ¿cuánto me
costará?
Un disco de datos premium creado a partir de un disco duro virtual de 80 GB se trata como el siguiente tamaño
de disco premium disponible, es decir, P10. Se le cobrará según el precio de disco P10.
¿Hay costos de transacción cuando se usan discos SSD premium?
Existe un costo fijo para cada tamaño de disco que esté aprovisionado con límites específicos de IOPS y
rendimiento. Los demás costes son por el ancho de banda de salida y la capacidad para instantáneas, si
corresponde. Consulte la página de preciospara obtener más información.
¿Cuáles son los límites de IOPS y rendimiento que puedo obtener de la caché de disco?
Los límites combinados de memoria caché y SSD local para la serie DS son 4000 IOPS por núcleo y 33 MiB por
segundo y núcleo. La serie GS ofrece 5000 IOPS por núcleo y 50 MiB por segundo y núcleo.
¿Es el SSD local compatible con máquinas virtuales de Managed Disks?
El SSD local es un almacenamiento temporal que se incluye con una máquina virtual de discos administrados. No
existe ningún costo extra para este almacenamiento temporal. Recomendamos que no use este SSD local para
almacenar los datos de la aplicación, ya que no se conserva en Azure Blob Storage.
¿Hay alguna repercusión en el uso de TRIM en discos premium?
No hay ningún inconveniente a la hora de usar TRIM en discos de Azure, ya sea en discos estándar o premium.
Nuevos tamaños de disco: Administrados y no administrados
¿Qué regiones admiten la capacidad de ráfagas para el tamaño de disco SSD Premium aplicable?
La capacidad de ráfaga se admite actualmente en el Centro-oeste de EE. UU. de Azure.

¿En qué regiones se admiten los tamaños de disco administrado de 4/8/16 GiB (P1/P2/P3, E1/E2/E3)?
Estos nuevos tamaños de disco se admiten actualmente en la región Centro-oeste de EE. UU. de Azure.
¿Se admiten los tamaños de disco P1/P2/P3 en discos no administrados o blobs en páginas?
No, solo se admite en discos administrados SSD premium admitidos.

¿Se admiten los tamaños de disco E1/E2/E3 en discos no administrados o blobs en páginas?
No, los discos administrados SSD estándar de cualquier tamaño no se pueden usar con discos no administrados
ni blobs en páginas.
¿Cuál es el mayor tamaño de disco administrado compatible con discos de datos y sistema operativo?
El tipo de partición compatible con Azure para un disco del sistema operativo es el registro de arranque maestro
(MBR ). El formato MBR admite un tamaño de disco de hasta 2 TiB. El tamaño máximo que admite Azure para un
disco del sistema operativo es de 2 TiB. Azure admite hasta 32 TiB para discos de datos administrados en Azure
global, 4 TiB en nubes soberanas de Azure.
¿Cuál es el mayor tamaño de disco administrado compatible con discos de datos y sistema operativo?
El tipo de partición compatible con Azure para un disco del sistema operativo es el registro de arranque maestro
(MBR ). El formato MBR admite un tamaño de disco de hasta 2 TiB. El tamaño máximo que admite Azure para un
disco no administrado del sistema operativo es de 2 TiB. Azure admite hasta 4 TiB para discos de datos no
administrados.
¿Cuál es el mayor tamaño de blob en páginas admitido?
El mayor tamaño de blob en páginas que admite Azure es 8 TiB (8191 GiB ). El tamaño máximo del blob en
páginas cuando se conecta a una máquina virtual como discos de datos o de sistema operativo es de 4 TiB
(4095 GiB ).
¿Es necesario usar una nueva versión de las herramientas de Azure para crear, conectar, cambiar de
tamaño y cargar discos de más de 1 TiB?
No es necesario actualizar las herramientas de Azure existentes para crear, conectar o cambiar el tamaño de los
discos de más de 1 TiB. Para cargar el archivo de disco duro virtual del entorno local directamente en Azure como
un blob en páginas o un disco no administrado, debe usar los conjuntos de herramientas más recientes que se
indican a continuación. Solo se admiten cargas de disco duro virtual de hasta 8 TiB.
HERRAMIENTAS DE AZURE VERSIONES COMPATIBLES
Azure PowerShell Número de versión 4.1.0: Versión de junio de 2017 o

posterior
CLI de Azure v1 Número de versión 0.10.13: Versión de mayo de 2017 o

posterior
CLI de Azure v2 Número de versión 2.0.12: Versión de julio de 2017 o

posterior
HERRAMIENTAS DE AZURE VERSIONES COMPATIBLES
AzCopy Número de versión 6.1.0: Versión de junio de 2017 o

posterior
¿Se admiten los tamaños de disco P4 y P6 para blobs en páginas o discos no administrados?
Los tamaños de disco P4 (32 GiB ) y P6 (64 GiB ) no se admiten como niveles de disco predeterminados para
discos no administrados y blobs en páginas. Deberá establecer el nivel de blob explícitamente en P4 y P6 para que
el disco se asigne a estos niveles. Si implementa un disco no administrado o un blob en páginas con el tamaño de
disco o la longitud de contenido inferior a 32 GiB o entre 32 y 64 GiB sin establecer el nivel de blob, continuará en
el nivel P10 con 500 IOPS y 100 MiB/s y el plan de tarifa asignado.
Si mi disco administrado premium existente de menos de 64 GiB se creó antes de habilitar el disco
pequeño (alrededor del 15 de junio de 2017), ¿cómo se factura?
Los discos pequeños premium de menos de 64 GiB se siguen facturando según el plan de tarifa P10.
¿Cómo puedo cambiar el nivel de disco de los discos pequeños premium menores de 64 GiB de P10 a P4
o P6?
Puede crear una instantánea de los discos pequeños y, después, crear un disco para cambiar automáticamente el
plan de tarifa a P4 o P6, en función del tamaño aprovisionado.
¿Puede cambiar el tamaño de las instancias de Managed Disks existentes de menos de 4 tebibytes (TiB )
a los nuevos tamaños de disco recién incorporados de hasta 32 TiB?
Sí.
¿Cuales son los tamaños de disco más grandes que admiten Azure Backup y el servicio Azure Site
Recovery?
El tamaño de disco más grande que admiten Azure Backup y el servicio Azure Site Recovery es de 4 TiB. La
compatibilidad con los discos de mayor tamaño de hasta 32 TiB aún no está disponible.
¿Cuáles son los tamaños de máquina virtual recomendados para los tamaños de disco mayores (> 4TiB )
para discos SSD estándar y HDD estándar con la finalidad de lograr niveles optimizados de ancho de
banda e IOPS del disco?
Para lograr el rendimiento de disco de los tamaños de discos grandes SSD y HDD estándar (>4 TiB ) más allá de
500 IOPS y 60 MiB/s, se recomienda implementar una nueva máquina virtual de uno de los siguientes tamaños
para optimizar el rendimiento: Máquinas virtuales de la serie B, serie DSv2, serie Dsv3, serie ESv3, serie Fs, serie
Fsv2, serie M, serie GS, serie NCv2, serie NCv3 o serie Ls. La asociación de discos de gran tamaño a máquinas
virtuales existentes o máquinas virtuales que no usan los tamaños recomendados anteriores puede dar lugar a un
rendimiento inferior.
¿Cómo puedo actualizar mis discos (> 4 TiB ) que se implementaron durante la versión preliminar de
tamaños de disco mayores con el fin de obtener el mayor ancho de banda e IOPS con carácter general?
Puede detener e iniciar la máquina virtual a la que está conectado el disco o bien desasociar y volver a asociar el
disco. Los objetivos de rendimiento de los tamaños de disco mayores han aumentado para discos SSD Premium y
estándar con carácter general.
¿En qué regiones se admiten los tamaños de disco administrado de 8 TiB, 16 TiB y 32 TiB?
Las SKU de disco de 8 TiB, 16 TiB y 32 TiB se admiten en todas las regiones en Azure global, Microsoft Azure
Government y Azure China 21Vianet.
¿Se admite la habilitación del almacenamiento en caché del host en todos los tamaños de disco?
Se admite el almacenamiento en caché del host de solo de lectura y de lectura y escritura en tamaños de disco
inferiores a 4 TiB. Para los tamaños de disco de más de 4 TiB, no se puede establecer la opción de almacenamiento
en caché en un valor distinto de Ninguno. Se recomienda aprovechar el almacenamiento en caché para tamaños
de disco más pequeños, donde se puede esperar un mayor aumento del rendimiento con datos almacenados en
caché en la máquina virtual.
Mi pregunta no está respondida aquí. ¿Qué debo hacer?

Si su pregunta no aparece aquí, háganoslo saber y lo ayudaremos a encontrar una respuesta. Puede publicar una
pregunta al final de este artículo en los comentarios. Para ponerse en contacto con el equipo de Azure Storage y
otros miembros de la Comunidad sobre este artículo, use el foro de Azure Storage de MSDN.
Para solicitar características, envíe sus solicitudes e ideas al foro de comentarios de Azure Storage.
Comandos comunes de PowerShell para Azure
Virtual Network
Si desea crear una máquina virtual, debe crear una red virtual o conocer una red virtual existente en la que pueda
agregar la máquina virtual. Normalmente, cuando se crea una máquina virtual, también hay que plantearse crear
los recursos que se describen en este artículo.
Consulte Cómo instalar y configurar Azure PowerShell para obtener más información sobre cómo instalar la
versión más reciente de Azure PowerShell, seleccionar la suscripción que quiere usar e iniciar sesión en su cuenta.
Algunas de las variables podrían serle útiles si ejecuta más de uno de los comandos de este artículo:
$location: la ubicación de los recursos de red. Puede usar Get-AzLocation para buscar una región geográfica
que se adapte a sus necesidades.
$myResourceGroup: el nombre del grupo de recursos donde se encuentran los recursos de red.
Crear recursos de red

TAREA GET-HELP
Crear configuraciones de subred $subnet1 = New-AzVirtualNetworkSubnetConfig -Name

"mySubnet1" -AddressPrefix XX.X.X.X/XX
$subnet2 = New-AzVirtualNetworkSubnetConfig -Name
"mySubnet2" -AddressPrefix XX.X.X.X/XX
Una red típica podría tener una subred para un equilibrador

de carga accesible desde Internet y una subred independiente
para un equilibrador de carga interno.
Creación de una red virtual $vnet = New-AzVirtualNetwork -Name "myVNet" -

ResourceGroupName $myResourceGroup -Location $location
-AddressPrefix XX.X.X.X/XX -Subnet $subnet1, $subnet2
Prueba para un nombre de dominio único Test-AzDnsAvailability -DomainNameLabel "myDNS" -Location

$location
Puede especificar un nombre de dominio DNS para un recurso

de dirección IP pública, lo que crea una asignación para
nombrededominio.ubicación.cloudapp.azure.com en la
dirección IP pública de los servidores DNS que administra
Azure. El nombre solo puede contener letras, números y
guiones. El primer y último carácter debe ser una letra o un
número y el nombre de dominio debe ser único dentro de su
ubicación de Azure. Si se devuelve True , significa que el
nombre propuesto es único globalmente.
Crear una dirección IP pública $pip = New-AzPublicIpAddress -Name "myPublicIp" -

ResourceGroupName $myResourceGroup -DomainNameLabel
"myDNS" -Location $location -AllocationMethod Dynamic
La dirección IP pública utiliza el nombre de dominio que probó

anteriormente y la emplea la configuración de front-end del
TAREA GET-HELP
Crear una configuración de direcciones IP de front-end $frontendIP = New-AzLoadBalancerFrontendIpConfig -Name

"myFrontendIP" -PublicIpAddress $pip
La configuración de front-end incluye la dirección IP pública

que creó anteriormente para el tráfico de red entrante.
Creación de un grupo de direcciones de back-end $beAddressPool = New-

AzLoadBalancerBackendAddressPoolConfig -Name
"myBackendAddressPool"
Proporciona direcciones internas para el back-end del

equilibrador de carga al que se accede mediante una interfaz
de red.
Elaboración de un sondeo $healthProbe = New-AzLoadBalancerProbeConfig -Name

"myProbe" -RequestPath 'HealthProbe.aspx' -Protocol http -
Port 80 -IntervalInSeconds 15 -ProbeCount 2
Contiene las sondas de estado utilizadas para comprobar la

disponibilidad de las instancias de máquina virtual del grupo
de direcciones de back-end.
Crear una regla de equilibrio de carga $lbRule = New-AzLoadBalancerRuleConfig -Name HTTP -

FrontendIpConfiguration $frontendIP -BackendAddressPool
$beAddressPool -Probe $healthProbe -Protocol Tcp -
FrontendPort 80 -BackendPort 80
Contiene reglas que asignan un puerto público del

equilibrador de carga a un puerto del grupo de direcciones de
back-end.
Crear una regla NAT entrante $inboundNATRule = New-

AzLoadBalancerInboundNatRuleConfig -Name
"myInboundRule1" -FrontendIpConfiguration $frontendIP -
Protocol TCP -FrontendPort 3441 -BackendPort 3389
Contiene reglas de asignación de un puerto público del

equilibrador de carga a un puerto de una máquina virtual
específica del grupo de direcciones de back-end.
Creación de un equilibrador de carga $loadBalancer = New-AzLoadBalancer -ResourceGroupName

$myResourceGroup -Name "myLoadBalancer" -Location
$location -FrontendIpConfiguration $frontendIP -
InboundNatRule $inboundNATRule -LoadBalancingRule
$lbRule -BackendAddressPool $beAddressPool -Probe
$healthProbe
TAREA GET-HELP
Crear una interfaz de red $nic1= New-AzNetworkInterface -ResourceGroupName

$myResourceGroup -Name "myNIC" -Location $location -
PrivateIpAddress XX.X.X.X -Subnet $subnet2 -
LoadBalancerBackendAddressPool
$loadBalancer.BackendAddressPools[0] -
LoadBalancerInboundNatRule
$loadBalancer.InboundNatRules[0]
Cree una interfaz de red empleando la dirección IP pública y la

subred de red virtual que creó anteriormente.
Obtención de información sobre recursos de red

TAREA GET-HELP
Enumerar redes virtuales Get-AzVirtualNetwork -ResourceGroupName

$myResourceGroup
Enumera todas las redes virtuales del grupo de recursos.
Obtener información sobre una red virtual Get-AzVirtualNetwork -Name "myVNet" -

ResourceGroupName $myResourceGroup
Enumerar subredes de una red virtual Get-AzVirtualNetwork -Name "myVNet" -

ResourceGroupName $myResourceGroup | Select Subnets
Obtener información sobre una subred Get-AzVirtualNetworkSubnetConfig -Name "mySubnet1" -

VirtualNetwork $vnet
Obtiene información sobre la subred de la red virtual

especificada. El valor $vnet representa el objeto devuelto por
Get-AzVirtualNetwork.
Enumerar direcciones IP Get-AzPublicIpAddress -ResourceGroupName

$myResourceGroup
Enumera las direcciones IP públicas del grupo de recursos.
Enumerar equilibradores de carga Get-AzLoadBalancer -ResourceGroupName

$myResourceGroup
Enumera todos los equilibradores de carga del grupo de

recursos.
Enumerar interfaces de red Get-AzNetworkInterface -ResourceGroupName

$myResourceGroup
Enumera todas las interfaces de red del grupo de recursos.
Obtener información sobre una interfaz de red Get-AzNetworkInterface -Name "myNIC" -

Obtiene información sobre una interfaz de red específica.

TAREA GET-HELP
Obtener la configuración de dirección IP de una interfaz de red Get-AzNetworkInterfaceIPConfig -Name "myNICIP" -

NetworkInterface $nic
Obtiene información sobre la configuración de dirección IP de

la interfaz de red especificada. El valor $nic representa el
objeto devuelto por Get-AzNetworkInterface.
Administración de recursos de red

TAREA GET-HELP
Agregar una red a una red virtual Add-AzVirtualNetworkSubnetConfig -AddressPrefix

XX.X.X.X/XX -Name "mySubnet1" -VirtualNetwork $vnet
Agrega una subred a una red virtual existente. El valor $vnet

representa el objeto devuelto por Get-AzVirtualNetwork.
Eliminar una red virtual Remove-AzVirtualNetwork -Name "myVNet" -

Quita la red virtual especificada del grupo de recursos.
Eliminar una interfaz de red Remove-AzNetworkInterface -Name "myNIC" -

Quita la interfaz de red especificada del grupo de recursos.
Eliminar un equilibrador de carga Remove-AzLoadBalancer -Name "myLoadBalancer" -

Quita el equilibrador de carga especificado del grupo de

recursos.
Eliminar una dirección IP pública Remove-AzPublicIpAddress-Name "myIPAddress" -

Quita la dirección IP pública especificada del grupo de

recursos.
Pasos siguientes
Utilice la interfaz de red que acaba de crear cuando cree una VM.
Obtenga información sobre cómo puede crear una máquina virtual con varias interfaces de red.
2 minutes to read
Apertura de puertos en una máquina virtual con
Azure Portal
En Azure, para abrir un puerto o crear un punto de conexión a una máquina virtual, debe crear un filtro de red en
una subred o una interfaz de red de máquina virtual. Estos filtros, que controlan el tráfico entrante y saliente, se
colocan en un grupo de seguridad de red asociado al recurso que va a recibir dicho tráfico.
El ejemplo de este artículo muestra cómo crear un filtro de red que utiliza el puerto TCP estándar 80 (se supone
ya ha iniciado los servicios apropiados y ha abierto las reglas de firewall del sistema operativo en la máquina
virtual).
Después de crear una máquina virtual configurada para atender las solicitudes web en el puerto TCP 80 estándar,
puede:
1. Cree un grupo de seguridad de red.
2. Crear una regla de seguridad de entrada que permita el tráfico y asignar valores a las siguientes opciones:
Intervalos de puertos de destino: 80
Intervalos de puertos de origen: * (permite cualquier puerto de origen)
Valor de prioridad: escriba un valor inferior a 65.500 (para que tenga mayor prioridad que la regla
de entrada predeterminada de denegación de comodín).
3. Asociar el grupo de seguridad de red con la subred o la interfaz de red de máquina virtual.
Aunque este ejemplo usa una regla sencilla para permitir el tráfico HTTP, también puede usar reglas y grupos de
seguridad de red para crear configuraciones de red más complejas.

Crear un grupo de seguridad de red

1. Busque y seleccione un grupo de recursos para la máquina virtual, elija Agregar y busque y seleccione
Grupo de seguridad de red.
Se abre la ventana Crear un grupo de seguridad de red.
3. Escriba un nombre para el grupo de seguridad de red.
4. Seleccione o cree un grupo de recursos y luego seleccione una ubicación.
5. Seleccione Crear para crear el grupo de seguridad de red.
Creación de una regla de seguridad de entrada

1. Seleccione el nuevo grupo de seguridad de red.
2. Seleccione Reglas de seguridad de entrada y luego Agregar.
3. Seleccione Advanced (Avanzadas).

4. Elija un servicio común en el menú desplegable, como HTTP. También puede seleccionar Personalizado
si quiere proporcionar un puerto específico para su uso.
5. Si lo desea, cambie la Prioridad o el Nombre. La prioridad afecta al orden en que se aplican las reglas
(cuanto más bajo es el valor numérico, antes se aplica la regla).
6. Para crear la regla, seleccione Agregar.
Asociación del grupo de seguridad de red con una subred

El paso final es asociar el grupo de seguridad de red a una subred o una interfaz de red específica. Para este
ejemplo, vamos a asociar el grupo de seguridad de red con una subred.
1. Seleccione Subredes y elija Asociar.
2. Seleccione la red virtual y luego seleccione la subred adecuada.
A través del puerto 80 se accede a las máquinas virtuales que se conectan a esa subred.
Información adicional
También puede llevar a cabo los pasos en este artículo utilizando Azure PowerShell.
Los comandos descritos en este artículo le permiten hacer que el tráfico fluya rápidamente a la máquina virtual.
Los grupos de seguridad de red proporcionan muchas características excelentes y granularidad para controlar el
acceso a sus recursos. Para más información, consulte Filtrado del tráfico de red con un grupo de seguridad de
red.
Para las aplicaciones web de alta disponibilidad, considere la posibilidad de colocar las máquinas virtuales detrás
de un equilibrador de carga de Azure. El equilibrador de carga distribuye el tráfico a las máquinas virtuales, con un
grupo de seguridad de red que proporciona el filtrado del tráfico. Para más información, consulte Equilibrio de
carga de máquinas virtuales Windows en Azure para crear una aplicación de alta disponibilidad.
Pasos siguientes
En este artículo ha creado un grupo de seguridad de red, creó una regla de entrada que permite el tráfico HTTP en
el puerto 80 y luego ha asociado esta regla con una subred.
Puede encontrar información sobre la creación de entornos más detallados en los siguientes artículos:
Información general sobre Azure Resource Manager
Grupos de seguridad
Apertura de puertos y puntos de conexión para una
máquina virtual en Azure mediante PowerShell
En Azure, para abrir un puerto o crear un punto de conexión a una máquina virtual, debe crear un filtro de red en
una subred o una interfaz de red de máquina virtual. Estos filtros, que controlan el tráfico entrante y saliente, se
colocan en un grupo de seguridad de red asociado al recurso que va a recibir dicho tráfico.
El ejemplo de este artículo muestra cómo crear un filtro de red que utiliza el puerto TCP estándar 80 (se supone
ya ha iniciado los servicios apropiados y ha abierto las reglas de firewall del sistema operativo en la máquina
virtual).
Después de crear una máquina virtual configurada para atender las solicitudes web en el puerto TCP 80 estándar,
puede:
1. Cree un grupo de seguridad de red.
2. Crear una regla de seguridad de entrada que permita el tráfico y asignar valores a las siguientes opciones:
Intervalos de puertos de destino: 80
Intervalos de puertos de origen: * (permite cualquier puerto de origen)
Valor de prioridad: escriba un valor inferior a 65.500 (para que tenga mayor prioridad que la regla
de entrada predeterminada de denegación de comodín).
3. Asociar el grupo de seguridad de red con la subred o la interfaz de red de máquina virtual.
Aunque este ejemplo usa una regla sencilla para permitir el tráfico HTTP, también puede usar reglas y grupos de
seguridad de red para crear configuraciones de red más complejas.
Comandos rápidos
Para crear reglas de los grupos de seguridad de red y ACL necesitará que esté instalada la versión más reciente
de Azure PowerShell. También puede llevar a cabo estos pasos con Azure Portal.
Inicie sesión en una cuenta de Azure:
Connect-AzAccount
En los ejemplos siguientes, reemplace los nombres de parámetros por los suyos propios. Los nombres de
parámetro de ejemplo incluían myResourceGroup, myNetworkSecurityGroup y myVnet.
Cree una regla con New -AzNetworkSecurityGroup. En el siguiente ejemplo crea una regla denominada
myNetworkSecurityGroupRule para permitir el tráfico TCP en el puerto 80:
$httprule = New-AzNetworkSecurityRuleConfig `
-Name "myNetworkSecurityGroupRule" `
-Description "Allow HTTP" `
-Access "Allow" `
-Protocol "Tcp" `
-Direction "Inbound" `
-Priority "100" `
-SourceAddressPrefix "Internet" `
-DestinationPortRange 80
A continuación, cree un grupo de seguridad de red con New -AzNetworkSecurityGroup y asigne la regla HTTP
que acaba de crear como se indica a continuación. En el ejemplo siguiente se crea un grupo de seguridad de red
denominado myNetworkSecurityGroup:
-Name "myNetworkSecurityGroup" `
-SecurityRules $httprule
Ahora hay que asignar el grupo de seguridad de red a una subred. En el ejemplo siguiente se asigna una red
virtual existente denominada myVnet a la variable $vnet con Get-AzVirtualNetwork:
-Name "myVnet"
Asocie el grupo de seguridad de red con la subred con Set-AzVirtualNetworkSubnetConfig. En el ejemplo

siguiente, se asocia la subred denominada mySubnet con un grupo de seguridad de red:
$subnetPrefix = $vnet.Subnets|?{$_.Name -eq 'mySubnet'}
Set-AzVirtualNetworkSubnetConfig `
-Name "mySubnet" `
-AddressPrefix $subnetPrefix.AddressPrefix `
-NetworkSecurityGroup $nsg
Por último, actualice la red virtual con Set-AzVirtualNetwork para que los cambios surtan efecto:
Más información sobre los grupos de seguridad de red

Los comandos rápidos que se describen aquí le permiten ponerse a trabajar con el flujo de tráfico a la máquina
virtual. Los grupos de seguridad de red proporcionan muchas características excelentes y un gran nivel de detalle
para controlar el acceso a sus recursos. Puede leer más sobre la creación de un grupo de seguridad de red y las
reglas de ACL aquí.
Para las aplicaciones web de alta disponibilidad, debe colocar las máquinas virtuales detrás de una instancia de
Azure Load Balancer. El equilibrador de carga distribuye el tráfico a las máquinas virtuales, con un grupo de
seguridad de red que proporciona el filtrado del tráfico. Para más información, consulte Equilibrio de la carga de
máquinas virtuales Linux en Azure para crear una aplicación de alta disponibilidad.
Pasos siguientes
En este ejemplo, se ha creado una regla sencilla para permitir tráfico HTTP. Puede encontrar información sobre la
creación de entornos más detallados en los siguientes artículos:
Información general sobre Azure Resource Manager
¿Qué es un grupo de seguridad de red?
Información general de Azure Resource Manager para equilibradores de carga
Creación de una máquina virtual con una dirección IP
pública estática mediante Azure Portal
Puede crear una máquina virtual con una dirección IP pública estática. Una dirección IP pública le permite
comunicarse con una máquina virtual desde Internet. Asigne una dirección IP pública estática, en lugar de una
dirección dinámica, para garantizar que la dirección no cambie nunca. Más información sobre direcciones IP
públicas estáticas. Para cambiar una dirección IP pública asignada a una máquina virtual existente de dinámica a
estática, o para trabajar con direcciones IP privadas, consulte Incorporación, cambio o eliminación de direcciones
IP. Las direcciones IP públicas tienen un costo nominal y hay un límite en el número de direcciones IP públicas que
se pueden usar por suscripción.

de una máquina virtual

1. Seleccione + Crear un recurso en la esquina superior izquierda de Azure Portal.
2. Seleccione Proceso y, luego, Máquina virtual de Windows Server 2016 u otro sistema operativo de su
elección.
3. Escriba o seleccione la siguiente información, acepte los valores predeterminados para el resto de la
configuración y luego seleccione Aceptar:
CONFIGURACIÓN VALOR
NOMBRE myVM
Nombre de usuario Escriba un nombre de usuario de su elección.
Password Escriba una contraseña de su elección. La contraseña debe

tener al menos 12 caracteres de largo y cumplir con los
requisitos de complejidad definidos.
Subscription Seleccione su suscripción.
Grupos de recursos Seleccione Usar existente y, a continuación,

myResourceGroup.
Ubicación Seleccione Este de EE. UU.
4. Seleccione un tamaño para la máquina virtual y luego Seleccionar.

5. En Configuración, seleccione Dirección IP pública.
6. Escriba myPublicIpAddress, seleccione Estática y luego seleccione Aceptar, tal y como se muestra en la
siguiente imagen:
Si la dirección IP pública debe ser una SKU estándar, seleccione Estándar en SKU. Más información sobre
las SKU de dirección IP pública. Si la máquina virtual se va a agregar al grupo back-end de una instancia
pública de Azure Load Balancer, la SKU de la dirección IP pública de la máquina virtual debe coincidir con la
SKU de la dirección IP del equilibrador de carga. Para más información, consulte Azure Load Balancer.
7. Seleccione un puerto o ningún puerto en Seleccionar puertos de entrada públicos. Se selecciona el
puerto 3389 para permitir el acceso remoto a la máquina virtual Windows Server desde Internet. No se
recomienda abrir el puerto 3389 desde Internet con cargas de trabajo de producción.
8. Acepte los valores predeterminados restantes y seleccione Aceptar.

9. En la página Resumen, seleccione Crear. La máquina virtual tarda minutos en crearse.
10. Una vez implementada la máquina virtual, escriba myPublicIpAddress en el cuadro de búsqueda de la parte
superior del portal. Cuando myPublicIpAddress aparezca en los resultados de búsqueda, selecciónela.
11. Puede ver la dirección IP pública asignada, y que la dirección se asigna a la máquina virtual myVM, como
se muestra en la siguiente imagen:
Azure asigna una dirección IP pública de las direcciones usadas en la región en la que creó la máquina
virtual. Puede descargar la lista de intervalos (prefijos) para las nubes de Azure Pública, Gobierno de
Estados Unidos, China y Alemania.
12. Seleccione Configuración para confirmar que la asignación es Estática.
WARNING
No modifique la configuración de direcciones IP dentro del sistema operativo de la máquina virtual. El sistema operativo no
conoce las direcciones IP públicas de Azure. Aunque puede agregar la configuración de dirección IP privada al sistema
operativo, se recomienda no hacerlo a menos que sea necesario y no hasta después de haber leído Incorporación o
eliminación de direcciones IP privadas a un sistema operativo.
Cuando ya no sea necesario, elimine el grupo de recursos y todos los recursos que contiene:
1. Escriba myResourceGroup en el cuadro Buscar que se encuentra en la parte superior del portal. Seleccione
myResourceGroup cuando lo vea en los resultados de la búsqueda.
2. Seleccione Eliminar grupo de recursos.
3. Escriba myResourceGroup para ESCRIBA EL NOMBRE DEL GRUPO DE RECURSOS: y seleccione
Eliminar.
Pasos siguientes
Más información acerca de direcciones IP públicas en Azure
Más información acerca de toda la configuración de dirección IP pública
Más información acerca de direcciones IP privadas y la asignación de una dirección IP privada estática a una
máquina virtual de Azure
Más información acerca de cómo crear máquinas virtuales Linux y Windows
Crear y administrar una máquina virtual con
Windows que tiene varias NIC
En Azure, las máquinas virtuales (VM ) pueden tener varias tarjetas de interfaz de red virtual (NIC ) conectadas a
ellas. Un escenario común es tener distintas subredes para la conectividad front-end y back-end. Puede asociar
varias NIC de una máquina virtual a varias subredes, pero esas subredes deben residir en la misma red virtual
(vNet). En este artículo se describe cómo crear una máquina virtual con varias NIC conectadas. También obtendrá
información sobre cómo agregar o quitar NIC de una máquina virtual existente. Diferentes tamaños de máquina
virtual admiten un número distinto de NIC, así que ajuste el tamaño de su máquina virtual teniendo esto en
cuenta.
Requisitos previos
En los ejemplos siguientes, reemplace los nombres de parámetros de ejemplo por los suyos propios. Los nombres
de parámetro de ejemplo incluyen myResourceGroup, myVnet y myVM.
Creación de una máquina virtual con varias NIC

En primer lugar, cree un grupo de recursos. En el ejemplo siguiente se crea un grupo de recursos denominado
myResourceGroup en la ubicación EastUs:
Creación de redes virtuales y subredes

Un escenario común es que una red virtual tenga dos o más subredes. Una subred puede ser para el tráfico de
front-end y la otra para el tráfico de back-end. Para conectarse a las dos subredes, se usan varias NIC en la
máquina virtual.
1. Defina dos subredes de red virtual con New -AzVirtualNetworkSubnetConfig. En el ejemplo siguiente se
definen dos subredes para mySubnetFrontEnd y mySubnetBackEnd:
$mySubnetFrontEnd = New-AzVirtualNetworkSubnetConfig -Name "mySubnetFrontEnd" `

-AddressPrefix "192.168.1.0/24"
$mySubnetBackEnd = New-AzVirtualNetworkSubnetConfig -Name "mySubnetBackEnd" `
2. Cree la red virtual y las subredes con New -AzVirtualNetwork. En el ejemplo siguiente se crea una red
virtual denominada myVnet:
$myVnet = New-AzVirtualNetwork -ResourceGroupName "myResourceGroup" `

-Location "EastUs" `
-Name "myVnet" `
-AddressPrefix "192.168.0.0/16" `
-Subnet $mySubnetFrontEnd,$mySubnetBackEnd
Creación de varias NIC

Cree dos NIC con New -AzNetworkInterface. Conecte una NIC a la subred de front-end y la otra a la subred de
back-end. En el ejemplo siguiente se crean las NIC denominadas myNic1 y myNic2:
$frontEnd = $myVnet.Subnets|?{$_.Name -eq 'mySubnetFrontEnd'}

$myNic1 = New-AzNetworkInterface -ResourceGroupName "myResourceGroup" `
-Name "myNic1" `
-SubnetId $frontEnd.Id
$backEnd = $myVnet.Subnets|?{$_.Name -eq 'mySubnetBackEnd'}

-Name "myNic2" `
-SubnetId $backEnd.Id
Normalmente también crea un grupo de seguridad de red para filtrar el tráfico de red a la máquina virtual y un
equilibrador de carga para distribuir el tráfico entre varias máquinas virtuales.
Comience ahora a compilar la configuración de la máquina virtual. El tamaño de cada máquina virtual tiene un
límite en cuanto al número total de NIC que se pueden agregar a una máquina virtual. Para más información, vea
Tamaños de las máquinas virtuales con Windows.
1. Establezca las credenciales de la máquina virtual en la variable $cred como se indica a continuación:
2. Defina la VM con New -AzVMConfig. En el ejemplo siguiente se define una máquina virtual denominada
myVM y se usa un tamaño de máquina virtual que admite hasta dos NIC ( Standard_DS3_v2):
$vmConfig = New-AzVMConfig -VMName "myVM" -VMSize "Standard_DS3_v2"
3. Cree el resto de la configuración de VM con Set-AzVMOperatingSystem y Set-AzVMSourceImage. En el

ejemplo siguiente se crea una máquina virtual con Windows Server 2016:
$vmConfig = Set-AzVMOperatingSystem -VM $vmConfig `

-Windows `
-ComputerName "myVM" `
-Credential $cred `
-ProvisionVMAgent `
-EnableAutoUpdate
$vmConfig = Set-AzVMSourceImage -VM $vmConfig `
-Offer "WindowsServer" `
-Skus "2016-Datacenter" `
-Version "latest"
4. Conecte las dos NIC que creó anteriormente con Add-AzVMNetworkInterface:
$vmConfig = Add-AzVMNetworkInterface -VM $vmConfig -Id $myNic1.Id -Primary

$vmConfig = Add-AzVMNetworkInterface -VM $vmConfig -Id $myNic2.Id
5. Cree la VM con New -AzVM:
New-AzVM -VM $vmConfig -ResourceGroupName "myResourceGroup" -Location "EastUs"

6. Agregue rutas de tarjetas NIC secundarias al sistema operativo mediante los pasos que se indican en
Configuración del sistema operativo invitado para varias NIC.
Adición de una NIC a una máquina virtual existente

Para agregar una NIC virtual a una máquina virtual existente, se desasigna la máquina virtual, se agrega la NIC
virtual y, después, se inicia la máquina virtual. Diferentes tamaños de máquina virtual admiten un número distinto
de NIC, así que ajuste el tamaño de su máquina virtual teniendo esto en cuenta. Si es necesario, puede cambiar el
tamaño de una máquina virtual.
1. Desasigne la VM con Stop-AzVM. En el ejemplo siguiente se desasigna la máquina virtual denominada
myVM en myResourceGroup:
Stop-AzVM -Name "myVM" -ResourceGroupName "myResourceGroup"
2. Obtenga la configuración existente de la VM con Get-AzVm. En el ejemplo siguiente se obtiene información

de la máquina virtual denominada myVM en myResourceGroup:
$vm = Get-AzVm -Name "myVM" -ResourceGroupName "myResourceGroup"
3. En el ejemplo siguiente se crea una NIC virtual con New -AzNetworkInterface denominada myNic3 que
está conectada a mySubnetBackEnd. Después, la NIC virtual se conecta a la VM denominada myVM en
myResourceGroup con Add-AzVMNetworkInterface:
# Get info for the back end subnet

$myVnet = Get-AzVirtualNetwork -Name "myVnet" -ResourceGroupName "myResourceGroup"
$backEnd = $myVnet.Subnets|?{$_.Name -eq 'mySubnetBackEnd'}
# Create a virtual NIC

-Name "myNic3" `
-SubnetId $backEnd.Id
# Get the ID of the new virtual NIC and add to VM

$nicId = (Get-AzNetworkInterface -ResourceGroupName "myResourceGroup" -Name "MyNic3").Id
Add-AzVMNetworkInterface -VM $vm -Id $nicId | Update-AzVm -ResourceGroupName "myResourceGroup"
NIC virtuales principales

En una máquina virtual de varias NIC una de las NIC debe ser la principal. Si una de las NIC virtuales
existentes en la máquina virtual ya se ha establecido como principal, puede omitir este paso. En el siguiente
ejemplo se da por supuesto que hay dos NIC virtuales en una máquina virtual y que se va a agregar la
primera NIC ( [0] ) como la principal:
# List existing NICs on the VM and find which one is primary

$vm.NetworkProfile.NetworkInterfaces
# Set NIC 0 to be primary

$vm.NetworkProfile.NetworkInterfaces[0].Primary = $true
$vm.NetworkProfile.NetworkInterfaces[1].Primary = $false
# Update the VM state in Azure

Update-AzVM -VM $vm -ResourceGroupName "myResourceGroup"
4. Inicie la VM con Start-AzVm:

Start-AzVM -ResourceGroupName "myResourceGroup" -Name "myVM"
5. Agregue rutas de tarjetas NIC secundarias al sistema operativo mediante los pasos que se indican en
Eliminación de una NIC de una máquina virtual existente

Para quitar una NIC virtual de una máquina virtual existente, se desasigna la máquina virtual, se quita la NIC
virtual y, después, se inicia la máquina virtual.
1. Desasigne la VM con Stop-AzVM. En el ejemplo siguiente se desasigna la máquina virtual denominada
myVM en myResourceGroup:
Stop-AzVM -Name "myVM" -ResourceGroupName "myResourceGroup"
2. Obtenga la configuración existente de la VM con Get-AzVm. En el ejemplo siguiente se obtiene información

de la máquina virtual denominada myVM en myResourceGroup:
$vm = Get-AzVm -Name "myVM" -ResourceGroupName "myResourceGroup"
3. Obtenga información sobre la eliminación de NIC con Get-AzNetworkInterface. En el ejemplo siguiente se

obtiene información sobre myNic3:
# List existing NICs on the VM if you need to determine NIC name

$vm.NetworkProfile.NetworkInterfaces
$nicId = (Get-AzNetworkInterface -ResourceGroupName "myResourceGroup" -Name "myNic3").Id
4. Quite la NIC con Remove-AzVMNetworkInterface y, después, actualice la VM con Update-AzVm. En el

ejemplo siguiente se quita myNic3 obtenida por $nicId en el paso anterior:
Remove-AzVMNetworkInterface -VM $vm -NetworkInterfaceIDs $nicId | `

Update-AzVm -ResourceGroupName "myResourceGroup"
5. Inicie la VM con Start-AzVm:
Start-AzVM -Name "myVM" -ResourceGroupName "myResourceGroup"
Crear varias NIC con plantillas

Las plantillas de Azure Resource Manager ofrecen una manera de crear varias instancias de un recurso durante la
implementación; por ejemplo, se pueden crear varias NIC. Las plantillas de Resource Manager usan archivos
JSON declarativos para definir el entorno. Para más información, vea Información general de Azure Resource
Manager. Puede usar copy para especificar el número de instancias que se crearán:
"copy": {
"name": "multiplenics",
"count": "[parameters('count')]"
}
Para más información, vea Creación de varias instancias mediante copy.

También puede usar copyIndex() para anexar un número a un nombre de recurso. Después, puede crear myNic1,
MyNic2 y así sucesivamente. En el código siguiente se muestra un ejemplo de cómo anexar el valor de índice:
"name": "[concat('myNic', copyIndex())]",
Puede leer un ejemplo completo de cómo crear varias NIC mediante plantillas de Resource Manager.
Agregue rutas de tarjetas NIC secundarias al sistema operativo mediante los pasos que se indican en
Configuración del sistema operativo invitado para varias NIC

Azure asigna una puerta de enlace predeterminada a la primera interfaz de red (principal) conectada a la máquina
virtual. Azure no asigna una puerta de enlace predeterminada a las interfaces de red adicionales (secundarias)
conectadas a una máquina virtual. Por lo tanto, de manera predeterminada, no es posible comunicarse con
recursos externos a la subred en la que se encuentra una interfaz de red secundaria. Sin embargo, las interfaces de
red secundarias pueden comunicarse con recursos externos a su subred, aunque los pasos necesarios para
habilitar la comunicación son diferentes para los distintos sistemas operativos.
1. Desde un símbolo del sistema de Windows, ejecute el comando route print . Este comando devuelve una
salida similar a la siguiente para una máquina virtual con dos interfaces de red conectadas:
===========================================================================
Interface List
3...00 0d 3a 10 92 ce ......Microsoft Hyper-V Network Adapter #3
7...00 0d 3a 10 9b 2a ......Microsoft Hyper-V Network Adapter #4
===========================================================================
En este ejemplo, Microsoft Hyper-V Network Adapter #4 (interfaz 7) es la interfaz de red secundaria que
no tiene una puerta de enlace predeterminada asignada.
2. Desde un símbolo del sistema, ejecute el comando ipconfig para ver la dirección IP asignada a la interfaz
de red secundaria. En este ejemplo, la dirección IP 192.168.2.4 está asignada a la interfaz 7. No se devuelve
ninguna dirección de puerta de enlace predeterminada para la interfaz de red secundaria.
3. Para que todo el tráfico destinado a direcciones que están fuera de la subred de la interfaz de red secundaria
se enrute a la puerta de enlace de la subred, ejecute el siguiente comando:
route add -p 0.0.0.0 MASK 0.0.0.0 192.168.2.1 METRIC 5015 IF 7
La dirección de la puerta de enlace para la subred es la primera dirección IP (terminada en .1) del intervalo
de direcciones definido para la subred. Si no quiere enrutar todo el tráfico fuera de la subred, puede agregar
rutas individuales a destinos específicos en su lugar. Por ejemplo, si solo quiere enrutar el tráfico de la
interfaz de red secundaria a la red 192.168.3.0, escriba el comando:
route add -p 192.168.3.0 MASK 255.255.255.0 192.168.2.1 METRIC 5015 IF 7
4. Para confirmar la comunicación correcta con un recurso en la red 192.168.3.0, por ejemplo, escriba el
siguiente comando para hacer ping a 192.168.3.4 mediante la interfaz 7 (192.168.2.4):
ping 192.168.3.4 -S 192.168.2.4
Puede que necesite abrir ICMP a través del firewall de Windows del dispositivo en el que está haciendo
ping con el siguiente comando:
netsh advfirewall firewall add rule name=Allow-ping protocol=icmpv4 dir=in action=allow
5. Para confirmar que la ruta agregada está en la tabla de rutas, escriba el comando route print , que
devuelve una salida similar al texto siguiente:
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.4 15
0.0.0.0 0.0.0.0 192.168.2.1 192.168.2.4 5015
La ruta que se muestra con 192.168.1.1 debajo de Puerta de enlace es la ruta que aparece de manera
predeterminada para la interfaz de red principal. La ruta con 192.168.2.1 debajo de Puerta de enlace es la
ruta agregada.
Pasos siguientes
Revise Tamaños de máquina virtual con Windows cuando esté intentando crear una máquina virtual que tiene
varias NIC. Preste atención al número máximo de NIC que admite cada tamaño de máquina virtual.
Creación de una máquina virtual Windows con
Accelerated Networking mediante Azure PowerShell
En este tutorial, aprenderá a crear una máquina virtual Windows con Accelerated Networking. Para crear una
máquina virtual Linux con redes aceleradas, consulte Creación de una máquina virtual Linux con redes aceleradas.
Accelerated Networking habilita la virtualización de E/S de raíz única (SR -IOV ) en una máquina virtual (VM ), lo
que mejora significativamente su rendimiento en la red. Este método de alto rendimiento omite el host de la ruta
de acceso de datos, lo que reduce la latencia, la inestabilidad y la utilización de la CPU para usarse con las cargas
de trabajo de red más exigentes en los tipos de máquina virtual admitidos. En la siguiente imagen, se muestra la
comunicación entre dos máquinas virtuales (VM ) con y sin Accelerated Networking:
Sin Accelerated Networking, todo el tráfico de red de entrada y salida de la máquina virtual tiene que atravesar el
host y el conmutador virtual. El conmutador virtual se encarga de toda la aplicación de directivas, como grupos de
seguridad de red, listas de control de acceso, aislamiento y otros servicios virtualizados de red, al tráfico de red.
Para obtener más información sobre los conmutadores virtuales, vea Hyper-V network virtualization and virtual
switch (Virtualización de red de Hyper-V y conmutador virtual).
Con Accelerated Networking, el tráfico de red llega a la interfaz de red (NIC ) de la máquina virtual y se reenvía
después a la máquina virtual. Todas las directivas de red que el conmutador virtual aplica se descargan y aplican
en el hardware. La aplicación de directivas en hardware permite que la NIC reenvíe el tráfico de red directamente a
la máquina virtual, pasando por alto el host y el conmutador virtual, al mismo tiempo que se mantienen todas las
directivas aplicadas en el host.
Las ventajas de Accelerated Networking solo se aplican a la máquina virtual donde esté habilitado. Para obtener
resultados óptimos, lo ideal es habilitar esta característica en al menos dos máquinas virtuales conectadas a la
misma instancia de Azure Virtual Network (VNet). Al comunicarse entre redes virtuales o conectarse de forma
local, esta característica tiene un efecto mínimo sobre la latencia total.
Ventajas
Menor latencia/Más paquetes por segundo (pps): al quitarse el conmutador virtual de la ruta de acceso de
datos, se elimina el tiempo que los paquetes pasan en el host para el procesamiento de las directivas y se
aumenta el número de paquetes que se pueden procesar dentro de la máquina virtual.
Inestabilidad reducida: el procesamiento del conmutador virtual depende de la cantidad de directivas que
deben aplicarse y la carga de trabajo de la CPU que se encarga del procesamiento. Al descargarse la aplicación
de directivas en el hardware, se elimina esa variabilidad, ya que los paquetes se entregan directamente a la
máquina virtual y se elimina el host de la comunicación de la máquina virtual, así como todas las
interrupciones de software y los cambios de contexto.
Disminución de la utilización de la CPU: el pasar por alto el conmutador virtual en el host conlleva una
disminución de la utilización de la CPU para procesar el tráfico de red.
Limitaciones y restricciones
Sistemas operativos compatibles
Se admiten las siguientes distribuciones de fábrica desde la galería de Azure:
Windows Server 2012 R2 Datacenter
Instancias de máquina virtual admitidas
Accelerated Networking se admite con la mayoría de los tamaños de instancia de uso general y optimizados para
procesos de dos o más vCPU. Estas series admitidas son: D/DSv2 y F/Fs
En instancias que admiten hyperthreading, las redes aceleradas se admiten en instancias de máquina virtual con
cuatro o más vCPU. Las series admitidas son: D/Dsv3, E/Esv3, Fsv2, Lsv2, Ms/Mms y Ms/Mmsv2.
Para más información sobre las instancias de máquinas virtuales, consulte Tamaños de las máquinas virtuales con
Windows.
Regions
Está disponible en todas las regiones públicas de Azure y la nube de Azure Government.
Habilitación de Accelerated Networking en una máquina virtual en ejecución
Un tamaño de máquina virtual admitido sin tener habilitado Accelerated Networking solo puede tener la
característica habilitada cuando se detiene o se desasigna la máquina virtual.
Implementación mediante Azure Resource Manager
Las máquinas virtuales (clásicas) no se pueden implementar con redes aceleradas.
Creación de una máquina virtual Windows con redes aceleradas de

Azure
Creación del portal
Aunque en este artículo se explica cómo crear una máquina virtual con redes aceleradas mediante Azure
PowerShell, también puede crear una máquina virtual con redes aceleradas mediante Azure Portal. Al crear una
máquina virtual en el portal, en la hoja Crear una máquina virtual, seleccione la pestaña Redes. En esta pestaña
hay una opción para Redes aceleradas. Si ha seleccionado un sistema operativo compatible y un tamaño de
máquina virtual, esta opción se rellena automáticamente como "Activado". Si no, se rellena la opción "Desactivado"
para Redes aceleradas y se proporciona al usuario un motivo de por qué no están habilitadas.
Nota: Solo los sistemas operativos compatibles se pueden habilitar a través del portal. Si usa una imagen
personalizada y esta es compatible con Redes aceleradas, cree la máquina virtual mediante la CLI o PowerShell.
Una vez creada la máquina virtual, puede confirmar que la opción Redes aceleradas está habilitada si sigue las
instrucciones que se indican en Confirmar que las redes aceleradas están habilitadas.
Creación de PowerShell
NOTE
Instale Azure PowerShell versión 1.0.0 o posterior. Para encontrar la versión instalada actualmente, ejecute
Get-Module -ListAvailable Az . Si necesita instalar o actualizar, instale la versión más reciente del módulo Az desde
la Galería de PowerShell. En una sesión de PowerShell, inicie sesión en una cuenta de Azure con Connect-
AzAccount.
En los ejemplos siguientes, reemplace los nombres de parámetros de ejemplo por los suyos propios. Los nombres
de parámetro de ejemplo incluían myResourceGroup, myNic y myVM.
Cree un grupo de recursos con New -AzResourceGroup. En el ejemplo siguiente, se crea un grupo de recursos
denominado myResourceGroup en la ubicación centralus:
New-AzResourceGroup -Name "myResourceGroup" -Location "centralus"
Primero, cree una configuración de subred con New -AzVirtualNetworkSubnetConfig. En el ejemplo siguiente se
crea una subred denominada mySubnet:
$subnet = New-AzVirtualNetworkSubnetConfig `
-Name "mySubnet" `
Cree una red virtual con New -AzVirtualNetwork, con la subred mySubnet.
$vnet = New-AzVirtualNetwork -ResourceGroupName "myResourceGroup" `

-Location "centralus" `
-Name "myVnet" `
-AddressPrefix "192.168.0.0/16" `
-Subnet $Subnet
Crear un grupo de seguridad de red

En primer lugar, cree una regla de grupo de seguridad de red con New -AzNetworkSecurityRuleConfig.
$rdp = New-AzNetworkSecurityRuleConfig `
-Name 'Allow-RDP-All' `
-Description 'Allow RDP' `
-Access Allow `
-Protocol Tcp `
-Priority 100 `
-DestinationPortRange 3389
Cree un grupo de seguridad de red con New -AzNetworkSecurityGroup y asígnele la regla de seguridad Allow -
RDP -All. Además de la regla Allow -RDP -All, el grupo de seguridad de red contiene varias reglas predeterminadas.
Una regla predeterminada deshabilita todo el acceso entrante desde Internet, lo que constituye la razón por la que
la regla Allow -RDP -All se asigna al grupo de seguridad de red para que pueda conectarla remotamente a la
máquina virtual, una vez que se crea.
-Location centralus `
-Name "myNsg" `
-SecurityRules $rdp
Asocie el grupo de seguridad de red a la subred mySubnet con Set-AzVirtualNetworkSubnetConfig. La regla en el

grupo de seguridad de red es eficaz para todos los recursos implementados en la subred.
Set-AzVirtualNetworkSubnetConfig `
-Name 'mySubnet' `
-AddressPrefix "192.168.1.0/24" `
-NetworkSecurityGroup $nsg
Creación de una interfaz de red con Accelerated Networking

Cree una dirección IP pública con New -AzPublicIpAddress. No se requiere una dirección IP pública si no tiene
pensado acceder a la máquina virtual desde Internet, pero, para completar los pasos de este artículo, sí es
necesaria.
$publicIp = New-AzPublicIpAddress `
-Name 'myPublicIp' `
-location centralus `
Cree una interfaz de red con New -AzNetworkInterface con la redes aceleradas habilitadas y asígnele la dirección
IP pública. En el ejemplo siguiente se crea una interfaz de red denominada myNic en mySubnet de la red virtual
myVnet y asigna la dirección IP pública myPublicIp :
$nic = New-AzNetworkInterface `
-Name "myNic" `
-Location "centralus" `
-SubnetId $vnet.Subnets[0].Id `
-PublicIpAddressId $publicIp.Id `
-EnableAcceleratedNetworking

Establezca las credenciales de la máquina virtual en la variable $cred con Get-Credential:
En primer lugar, defina la máquina virtual con New -AzVMConfig. En el ejemplo siguiente se define una máquina
virtual denominada myVM con un tamaño que admite Accelerated Neworking (Standard_DS4_v2):
$vmConfig = New-AzVMConfig -VMName "myVm" -VMSize "Standard_DS4_v2"
Para obtener una lista de todos los tamaños de máquinas virtuales y las características, consulte tamaños de
máquina virtual de Windows.
Cree el resto de la configuración de VM con Set-AzVMOperatingSystem y Set-AzVMSourceImage. En el ejemplo
siguiente se crea una máquina virtual con Windows Server 2016:
$vmConfig = Set-AzVMOperatingSystem -VM $vmConfig `

-Windows `
-ComputerName "myVM" `
-Credential $cred `
-ProvisionVMAgent `
-EnableAutoUpdate
$vmConfig = Set-AzVMSourceImage -VM $vmConfig `
-Offer "WindowsServer" `
-Skus "2016-Datacenter" `
-Version "latest"
Adjunte la interfaz de red creada anteriormente con Add-AzVMNetworkInterface:
$vmConfig = Add-AzVMNetworkInterface -VM $vmConfig -Id $nic.Id
Por último, cree la máquina virtual con New -AzVM:
New-AzVM -VM $vmConfig -ResourceGroupName "myResourceGroup" -Location "centralus"
Confirmación de que el controlador está instalado en el sistema

operativo
Una vez creada la máquina virtual en Azure, conéctese a ella y confirme que el controlador está instalado en
Windows.
1. Desde un explorador de Internet, abraAzure Portal e inicie sesión con su cuenta de Azure.
2. En el cuadro que contiene el texto Buscar recursos, en la parte superior de Azure Portal, escriba myVm.
Haga clic en MyVm cuando aparezca en los resultados de búsqueda. Si Creando está visible en el botón
Conectar, Azure aún no ha terminado de crear la máquina virtual. Haga clic en Conectar en la esquina
superior izquierda de la información general, pero solo después de que ya no se vea Creando en el botón
Conectar.
3. Escriba el nombre de usuario y la contraseña que escribió en Creación de la máquina virtual. Si nunca se ha
conectado a una máquina virtual Windows en Azure, consulte Conexión a la máquina virtual.
4. Haga clic con el botón derecho en el botón Inicio de Windows y haga clic en Administrador de
dispositivos. Expanda el nodo Adaptadores de red. Compruebe que el Adaptador Ethernet de función
virtual ConnectX-3 de Mellanox aparezca como se muestra en la siguiente imagen:
Las redes aceleradas ya están habilitadas para su máquina virtual.
Habilitación de Accelerated Networking en máquinas virtuales

existentes
Si ha creado una VM sin Accelerated Networking, es posible habilitar esta característica en una VM existente. Para
admitir Accelerated Networking, la VM debe cumplir los siguientes requisitos previos que también se han descrito
anteriormente:
La VM debe tener un tamaño admitido para Accelerated Networking.
La VM debe ser una imagen admitida de la galería de Azure (y la versión de kernel de Linux).
Todas las máquinas virtuales de un conjunto de disponibilidad o VMSS se deben detener o desasignar antes de
habilitar Accelerated Networking en cualquier NIC.
VM individuales y VM de un conjunto de disponibilidad
En primer lugar, detenga o desasigne la VM o, en el caso de un conjunto de disponibilidad, todas las VM del
conjunto:
Stop-AzVM -ResourceGroup "myResourceGroup" `

-Name "myVM"
Es importante tener en cuenta que, si la máquina virtual se creó de forma individual, sin un conjunto de
disponibilidad, solo es necesario detener o desasignar esa máquina virtual individual para habilitar Accelerated
Networking. Si la máquina virtual se creó con un conjunto de disponibilidad, será necesario detener o desasignar
todas las máquinas virtuales contenidas en el conjunto de disponibilidad antes de habilitar Accelerated
Networking en cualquiera de las NIC.
Una vez detenida, habilite Accelerated Networking en la NIC de la máquina virtual:
$nic = Get-AzNetworkInterface -ResourceGroupName "myResourceGroup" `

-Name "myNic"
$nic.EnableAcceleratedNetworking = $true
$nic | Set-AzNetworkInterface
Reinicie la máquina virtual o, en el caso de un conjunto de disponibilidad, todas las máquinas virtuales del
conjunto, y confirme que las redes aceleradas están habilitadas:
Start-AzVM -ResourceGroup "myResourceGroup" `

-Name "myVM"
VMSS
VMSS es ligeramente diferente, pero sigue el mismo flujo de trabajo. En primer lugar, detenga las VM:
Stop-AzVmss -ResourceGroupName "myResourceGroup" `

Una vez detenidas las VM, actualice la propiedad Accelerated Networking bajo la interfaz de red:
$vmss = Get-AzVmss -ResourceGroupName "myResourceGroup" `

$vmss.VirtualMachineProfile.NetworkProfile.NetworkInterfaceConfigurations[0].EnableAcceleratedNetworking =
$true
Update-AzVmss -ResourceGroupName "myResourceGroup" `

Tenga en cuenta que un VMSS tiene actualizaciones de VM que aplican actualizaciones mediante tres valores
diferentes: automático, gradual y manual. En estas instrucciones, la directiva se establece en automático para que el
VMSS recoja los cambios inmediatamente después de reiniciarse. Para establecerla en automático para que los
cambios se recojan inmediatamente:
$vmss.UpgradePolicy.AutomaticOSUpgrade = $true
Update-AzVmss -ResourceGroupName "myResourceGroup" `

Por último, reinicie el VMSS:
Start-AzVmss -ResourceGroupName "myResourceGroup" `

Después de reiniciar, espere a que las actualizaciones finalicen y la función virtual aparecerá dentro de la máquina
virtual. (Asegúrese de que usa un tamaño admitido de sistema operativo y máquina virtual).
Cambio del tamaño de las máquinas virtuales existentes con las redes aceleradas
Las VM con Accelerated Networking habilitado solo pueden cambiar al tamaño de VM que admitan Accelerated
Networking.
Una VM con Accelerated Networking habilitado no puede cambiar al tamaño de una instancia de VM que no
admita Accelerated Networking mediante la operación de cambio de tamaño. Para cambiar el tamaño de una de
estas VM, debe hacer lo siguiente:
Detener o desasignar la VM o, si se trata de un conjunto de disponibilidad o VMSS, detener o desasignar todas
las VM del conjunto o VMSS.
Accelerated Networking debe estar deshabilitado en la NIC de la VM o, si está en un conjunto de
disponibilidad o VMSS, de todas las VM del conjunto o VMSS.
Una vez deshabilitadas, la máquina virtual, el conjunto de disponibilidad o el VMSS se pueden mover a un
nuevo tamaño que no admita redes aceleradas y reiniciarse.
Creación de un nombre de dominio completo en
Azure Portal para una máquina virtual Windows
Cuando crea una máquina virtual (VM ) en Azure Portal, se crea automáticamente un recurso de IP pública para la
máquina virtual. Use esta dirección IP para acceder de forma remota a la máquina virtual. Aunque el portal no
crea un nombre de dominio completo, o FQDN, puede crear uno cuando se crea la máquina virtual. Este artículo
muestra los pasos para crear un nombre DNS o FQDN.
Creación de un FQDN
En este artículo se supone que ya ha creado una máquina virtual. Si es necesario, puede crear una máquina virtual
en el portal o con Azure PowerShell. Una vez que la máquina virtual está en funcionamiento, siga estos pasos:
1. Seleccione la máquina virtual en el portal. En Nombre DNS, haga clic en Configurar.
2. Escriba el nombre DNS deseado y haga clic en Guardar.

3. Para volver a la hoja de información general de la máquina virtual, cierre la hoja Dirección IP pública.
Compruebe que se muestra ahora el Nombre DNS.
Ahora puede conectarse de forma remota a la máquina virtual con este nombre DNS, por ejemplo, para el
protocolo de escritorio remoto (RDP ).
Pasos siguientes
Ahora que la máquina virtual tiene un nombre DNS y una IP pública, puede implementar marcos o servicios de
aplicaciones comunes, como IIS, SQL o SharePoint.
En Información general sobre Azure Resource Manager encontrará sugerencias sobre la creación de
implementaciones de Azure.
Funcionamiento de Azure DNS con otros servicios de
Azure
Azure DNS es un servicio de resolución de nombres y administración de DNS hospedado. Puede usarlo para crear
nombres DNS públicos para las otras aplicaciones y servicios que tiene implementados en Azure. Crear un
nombre para un servicio de Azure en su dominio personalizado es sencillo. Solo tiene que agregar un registro del
tipo correcto para el servicio.
Para las direcciones IP asignadas dinámicamente, puede crear un registro CNAME de DNS que se asigna al
nombre DNS que Azure creó para el servicio. Los estándares DNS evitan que use un registro CNAME para el
vértice de la zona. Puede usar un registro de alias en su lugar. Para más información, consulte Tutorial:
Configuración de un registro de alias para hacer referencia a una dirección IP pública de Azure.
Para las direcciones IP asignadas de forma estática, puede crear un registro D de DNS con cualquier nombre,
incluido un nombre de dominio simple en el vértice de la zona.
En la tabla siguiente se describen los tipos de registro admitidos que se pueden usar para diversos servicios de
Azure. Como muestra la tabla, Azure DNS solo admite registros DNS para recursos de red orientados a Internet.
Azure DNS no se puede usar para la resolución de nombres de direcciones privadas internas.
SERVICIO DE AZURE INTERFAZ DE RED DESCRIPCIÓN
Azure Application Gateway Dirección IP pública front-end Puede crear un registro D o CNAME de
DNS.
Azure Load Balancer Dirección IP pública front-end Puede crear un registro D o CNAME de
DNS. Load Balancer puede tener una
dirección IP pública IPv6 que se asigna
dinámicamente. Cree un registro
CNAME para una dirección IPv6.
Administrador de tráfico de Azure Nombre público Puede crear un registro de alias que se
asigne al nombre de trafficmanager.net
que está asignado a su perfil de Traffic
Manager. Para más información,
consulte Tutorial: Configuración de un
registro de alias para admitir nombres
de dominio de Apex con Traffic
Manager.
Azure Cloud Services Dirección IP pública Para las direcciones IP asignadas de

forma estática, puede crear un registro
D de DNS. Para las direcciones IP
asignadas dinámicamente, debe crear
un registro CNAME que se asigne al
nombre de cloudapp.net .
SERVICIO DE AZURE INTERFAZ DE RED DESCRIPCIÓN
Azure App Service Dirección IP externa Para las direcciones IP externas, puede
crear un registro D de DNS. De lo
contrario, deberá crear un registro
CNAME que se asigne al nombre de
azurewebsites.net. Para más
información, consulte Asignación de un
nombre de dominio personalizado a
una aplicación de Azure.
Máquinas virtuales de Azure Resource Dirección IP pública Las máquinas virtuales de Resource
Manager Manager pueden tener direcciones IP
públicas. Una máquina virtual con una
dirección IP pública también puede
encontrarse detrás de un equilibrador
de carga. Puede crear un registro D de
DNS, CNAME o de alias para la dirección
pública. Puede usar este nombre
personalizado para omitir la dirección IP
virtual en el equilibrador de carga.
Máquinas virtuales clásicas Dirección IP pública Las máquinas virtuales clásicas creadas
con PowerShell o con la CLI se pueden
configurar con una dirección virtual
dinámica o estática (reservada). Puede
crear un registro CNAME o D de DNS,
respectivamente.
Características y extensiones de las máquinas
virtuales de Azure
Las extensiones de máquina virtual (VM ) de Azure son pequeñas aplicaciones que proporcionan tareas de
configuración y automatización tras la implementación en máquinas virtuales de Azure. Puede usar imágenes
existentes y, después, personalizarlas como parte de las implementaciones, lo que le ahorra el trabajo de compilar
imágenes personalizadas.
La plataforma de Azure hospeda numerosas extensiones, que abarcan aplicaciones de configuración, supervisión,
seguridad y utilidad de máquinas virtuales. Los publicadores toman una aplicación, la encapsulan en una
extensión y simplifican la instalación, de modo que lo único que debe hacer es proporcionar los parámetros
obligatorios.
Existe una amplia variedad de extensiones propias y de terceros. Si la aplicación del repositorio de extensiones no
existe, puede usar la extensión de script personalizado y configurar la máquina virtual con sus propios comandos
y scripts.
Ejemplos de escenarios clave para los que se usan extensiones:
Configuración de máquinas virtuales. Puede usar extensiones de DSC (Desired State Configuration) de
Powershell, Chef, Puppet y script personalizado para instalar agentes de configuración de máquina virtual y
configurar la máquina virtual.
Productos de antivirus, como Symantec y ESET.
Herramientas de vulnerabilidad de máquina virtual, como Qualys, Rapid7 y HPE.
Herramientas de supervisión de máquinas virtuales y aplicaciones, como DynaTrace, Azure Network Watcher,
Site24x7 y Stackify.
Las extensiones se pueden incluir con una nueva implementación de máquina virtual. Por ejemplo, puede formar
parte de una implementación más amplia que configure aplicaciones en el aprovisionamiento de máquinas
virtuales o se ejecute en cualquier sistema operado por extensiones admitido tras la implementación.
¿Cómo puedo encontrar qué extensiones están disponibles?

Puede ver las extensiones disponibles en la hoja Máquina virtual del portal, en Extensiones. Aquí solo se
presentan algunas de ellas; para ver la lista completa, use las herramientas de la CLI. Vea Discovering VM
Extensions for Linux (Detección de extensiones de máquina virtual para Linux) y Discovering VM Extensions for
Windows (Detección de extensiones de máquina virtual para Windows).
¿Cómo puedo instalar una extensión?

Las extensiones de máquina virtual de Azure se pueden administrar con la CLI de Azure, Azure PowerShell,
plantillas de Azure Resource Manager y Azure Portal. Para probar una extensión, vaya a Azure Portal, seleccione la
extensión de script personalizado, pase un comando o script y ejecute las extensiones.
Si quiere la misma extensión que agregó en el portal mediante la CLI o la plantilla de Resource Manager, vea otra
documentación sobre extensiones, como Extensión de script personalizado para Windows y Extensión de script
personalizado para Linux.
¿Cómo administro el ciclo de vida de las aplicaciones de extensión?

No es necesario conectarse directamente a una máquina virtual para instalar o eliminar la extensión. Como el
ciclo de vida de las aplicaciones de extensión de Azure se administra fuera de la máquina virtual y se integra en la
plataforma de Azure, también obtiene el estado integrado de la extensión.
¿Debo tener en cuenta algo más sobre las extensiones?

Las extensiones instalan las aplicaciones. Como en todas las aplicaciones, existen algunos requisitos. En el caso de
las extensiones, hay una lista de sistemas operativos de Windows y Linux admitidos. Además, debe tener
instalados los agentes de máquina virtual de Azure. Algunas aplicaciones de extensión de máquina virtual
individuales pueden tener sus propios requisitos previos de entorno, como el acceso a un punto de conexión.
Extensiones de solución de problemas

Puede encontrar información de solución de problemas para cada extensión en la sección Solución de
problemas y soporte técnico de la información general de la extensión. A continuación se enumera la
información de solución de problemas disponible:
ESPACIO DE NOMBRES SOLUCIÓN DE PROBLEMAS
microsoft.azure.monitoring.dependencyagent.dependencyage Dependencia de Azure Monitor para Linux

ntlinux
microsoft.azure.monitoring.dependencyagent.dependencyage Dependencia de Azure Monitor para Windows

ntwindows
microsoft.azure.security.azurediskencryptionforlinux Azure Disk Encryption para Linux
microsoft.azure.security.azurediskencryption Azure Disk Encryption para Windows
microsoft.compute.customscriptextension Script personalizado para Windows
microsoft.ostcextensions.customscriptforlinux para Linux
microsoft.powershell.dsc Desired State Configuration para Windows
microsoft.hpccompute.nvidiagpudriverlinux Extensión del controlador de GPU de NVIDIA para Linux
microsoft.hpccompute.nvidiagpudriverwindows Extensión del controlador de GPU de NVIDIA para Windows
microsoft.azure.security.iaasantimalware Extensión de Antimalware para Windows
microsoft.enterprisecloud.monitoring.omsagentforlinux Azure Monitor para Linux
microsoft.enterprisecloud.monitoring.microsoftmonitoringage Azure Monitor para Windows

nt
stackify.linuxagent.extension.stackifylinuxagentextension Stackify Retrace para Linux
vmaccessforlinux.microsoft.ostcextensions Restablecimiento de contraseña (VMAccess) para Linux
microsoft.recoveryservices.vmsnapshot Instantánea para Linux
microsoft.recoveryservices.vmsnapshot Instantánea para Windows

Pasos siguientes
Para más información sobre cómo funcionan las extensiones y el agente de Linux, vea Azure VM extensions
and features for Linux (Características y extensiones de máquina virtual de Azure para Linux).
Para más información sobre cómo funcionan las extensiones de Windows y Windows Guest Agent, consulte
Características y extensiones de las máquinas virtuales de Azure para Windows.
Para instalar Windows Guest Agent, vea Información general del agente de máquina virtual de Azure.
Para instalar el agente de Linux, vea Información y uso del agente de Linux de Azure.
Movimiento de una máquina virtual Windows a otro
grupo de recursos o suscripción de Azure
Este artículo le guiará en el procedimiento para mover una máquina virtual (VM ) Windows entre suscripciones o
grupos de recursos. Mover máquinas virtuales entre suscripciones puede ser útil si originalmente creó una en una
suscripción personal y ahora quiere moverla a la suscripción de su compañía para seguir trabajando. Para poder
mover la máquina virtual, no es necesario iniciarla y debe mantenerse en ejecución durante el desplazamiento.
IMPORTANT
Como parte de esta operación, se crean nuevos identificadores de recurso. Después de haber movido la VM, debe actualizar
sus herramientas y scripts para usar los nuevos id. de recursos.
Uso de Azure Portal para mover una VM a otra suscripción

Puede mover una VM y sus recursos asociados a otra suscripción mediante Azure Portal.
2. Haga clic en Examinar > Grupos de recursos y seleccione el grupo de recursos que contiene la VM que quiere
mover.
3. En la parte superior de la página para el grupo de recursos, seleccione Mover y, luego, seleccione Mover a otra
suscripción. Se abre la página Mover recursos.
4. Seleccione cada uno de los recursos que quiere mover. En la mayoría de los casos, debe mover todos los
recursos relacionados que se muestran.
5. Seleccione la suscripción adonde quiere mover la máquina virtual.
6. Seleccione un grupo de recursos existente o escriba un nombre para que se cree uno.
7. Cuando haya terminado, seleccione que comprende que se crearán nuevos identificadores de recursos y que los
nuevos identificadores se deberán usar con la VM después de que se mueva. Luego seleccione Aceptar.
Uso de Azure Portal para mover una VM a otro grupo de recursos

Puede mover una VM y sus recursos asociados a otro grupo de recursos mediante Azure Portal.
2. Haga clic en Examinar > Máquinas virtuales y seleccione la máquina virtual que desee mover de la lista.
3. En la página de la VM, junto a la etiqueta para el grupo de recursos, seleccione Cambiar. Se abre la página
Mover recursos.
4. Seleccione cada uno de los recursos que quiere mover. En la mayoría de los casos, debe mover todos los
recursos relacionados que se muestran.
5. Seleccione un grupo de recursos existente o escriba un nombre para que se cree uno.
6. Cuando haya terminado, seleccione que comprende que se crearán nuevos identificadores de recursos y que los
nuevos identificadores se deberán usar con la VM después de que se mueva. Luego seleccione Aceptar.
Uso de PowerShell para mover una máquina virtual

Para mover una máquina virtual a otro grupo de recursos, debe asegurarse de trasladar todos los recursos
dependientes. Para obtener una lista con el identificador de recurso de cada uno de estos recursos, use el cmdlet
Get-AzResource.
Get-AzResource -ResourceGroupName <sourceResourceGroupName> | Format-list -wrap -Property ResourceId
Se puede usar la salida del comando anterior como lista separada por comas de identificadores de recursos de
Move-AzResource para mover cada recurso hasta el destino.
Move-AzResource -DestinationResourceGroupName "<myDestinationResourceGroup>" `

-ResourceId <myResourceId,myResourceId,myResourceId>
Para mover los recursos a otra suscripción, incluya el parámetro -DestinationSubscriptionId .
Move-AzResource -DestinationSubscriptionId "<myDestinationSubscriptionID>" `

-DestinationResourceGroupName "<myDestinationResourceGroup>" `
-ResourceId <myResourceId,myResourceId,myResourceId>
Cuando se le pida que confirme que quiere mover los recursos especificados, escriba Y para confirmar.
Pasos siguientes
Puede mover muchos tipos diferentes de recursos entre suscripciones y grupos de recursos. Para obtener más
información, consulte Traslado de los recursos a un nuevo grupo de recursos o a una nueva suscripción.
Traslado de máquinas virtuales de Azure a otra
región
Hay varios escenarios en los que puede desear mover las máquinas virtuales de Azure IaaS existentes de una
región a otra. Por ejemplo, si desea mejorar la confiabilidad y disponibilidad de las máquinas virtuales existentes,
para mejorar la capacidad de administración, o si quiere moverlas por motivos de gobernanza. Para más
información, consulte Introducción al traslado de máquinas virtuales de Azure.
Puede usar el servicio Azure Site Recovery para administrar y coordinar la recuperación ante desastres de
máquinas locales y máquinas virtuales de Azure para la continuidad empresarial y recuperación ante desastres
(BCDR ). También puede usar Site Recovery para administrar el movimiento de máquinas virtuales de Azure a una
región secundaria.
En este tutorial, aprenderá lo siguiente:
Comprobar los requisitos previos para el traslado
Preparar las máquinas virtuales de origen y la región de destino
Copiar los datos y habilitar la replicación
Probar la configuración y realizar el traslado
Eliminar los recursos en la región de origen
NOTE
En este tutorial se muestra cómo trasladar las máquinas virtuales de Azure de una región a otra tal cual. Si tiene que mejorar
la disponibilidad moviendo las máquinas virtuales en un conjunto de disponibilidad a máquinas virtuales ancladas a la zona
en una región distinta, consulte el tutorial Traslado de máquinas virtuales de Azure a zonas de disponibilidad.
Requisitos previos
Asegúrese de tener las máquinas virtuales de Azure en la región de Azure desde la que va a realizar el
traslado.
Compruebe si se admite la combinación de región de origen y región de destino que ha elegido y tome una
decisión informada sobre la región de destino.
Asegúrese de entender la arquitectura y los componentes del escenario.
Revise las limitaciones y los requisitos de compatibilidad.
Compruebe los permisos de la cuenta. Si ha creado su cuenta de Azure gratis, ya es el administrador de la
suscripción. Si no es el administrador de la suscripción, solicite al administrador que le asigne los permisos
que necesita. Para habilitar la replicación para una máquina virtual y esencialmente copiar los datos
mediante Azure Site Recovery, tiene que tener:
Permisos para crear una máquina virtual en recursos de Azure. El rol integrado "Colaborador de la
máquina virtual" tiene estos permisos, que incluyen:
Permiso para crear una máquina virtual en el grupo de recursos seleccionado.
Permiso para crear una máquina virtual en la red virtual seleccionada
Permiso para escribir en la cuenta de almacenamiento seleccionada
Permisos para administrar las operaciones de Azure Site Recovery. El rol "Colaborador de Site
Recovery" tiene todos los permisos necesarios para administrar las operaciones de Site Recovery en
un almacén de Recovery Services.
Asegúrese de que todos los certificados raíz más recientes están en las máquinas virtuales de Azure que
quiera trasladar. Si los certificados raíz más recientes no están presentes en la máquina virtual, las
restricciones de seguridad no permitirán la copia de datos en la región de destino.
Para las máquinas virtuales de Windows, instale las actualizaciones de Windows más recientes en la
máquina virtual, de modo que todos los certificados raíz de confianza estén en ella. En un entorno
desconectado, siga los procesos estándar de actualización de certificados y de Windows Update en su
organización.
En las máquinas virtuales Linux, para obtener los certificados raíz de confianza y la lista de revocación de
certificados en la máquina virtual, siga las instrucciones proporcionadas por su distribuidor de Linux.
Asegúrese de que no utiliza un proxy de autenticación para controlar la conectividad de red de las máquinas
virtuales que quiere trasladar.
Si la máquina virtual que está intentando trasladar no tiene acceso a Internet, o utiliza un proxy de firewall
para controlar el acceso de salida, compruebe los requisitos.
Identifique el diseño de red de origen y todos los recursos que está usando actualmente. Esto incluye, pero
no se limita a los equilibradores de carga, grupos de seguridad de red (NSG ), e IP públicas.
Compruebe que su suscripción de Azure permite crear máquinas virtuales en la región de destino que se
usa para la recuperación ante desastres. Para habilitar la cuota necesaria, póngase en contacto con el
soporte técnico.
Asegúrese de que su suscripción tiene suficientes recursos para admitir máquinas virtuales con tamaños
que se correspondan con las máquinas virtuales de origen. Si está usando Site Recovery para copiar datos
en el destino, Site Recovery elije el mismo tamaño para la máquina virtual de destino o el más cercano
posible.
Asegúrese de que crea un recurso de destino para cada componente identificado en el diseño de la red de
origen. Este paso es importante para asegurarse de que las máquinas virtuales tengan en la región de
destino toda la funcionalidad y características que tenían en la región de origen.
NOTE
Azure Site Recovery automáticamente detecta y crea una red virtual al habilitar la replicación para la máquina virtual
de origen. También puede crear previamente una red y asignarla a la máquina virtual en el flujo de usuario para
habilitar la replicación. Como se menciona a continuación, es necesario crear manualmente cualquier otro recurso en
la región de destino.
Para crear los recursos de red más utilizados que considere apropiados, en función de la configuración de la
máquina virtual de origen, consulte la siguiente documentación:
Dirección IP pública
Para cualquier otro componente de red, consulte la documentación de red.
Preparación
En los pasos siguientes se muestra cómo preparar la máquina virtual para el movimiento mediante Azure Site
Recovery como una solución.
Cree el almacén en cualquier región, excepto en la de origen
1. Inicie sesión en Azure Portal > Recovery Services.
2. Seleccione Crear un recurso > Herramientas de administración > Backup and Site Recovery.
3. En el apartado Nombre, especifique el nombre descriptivo ContosoVMVault. Si tiene más de una suscripción,
seleccione la apropiada.
4. Cree un grupo de recursos denominado ContosoRG.
5. Especifique una región de Azure. Para comprobar las regiones admitidas, consulte la disponibilidad geográfica
en Detalles de precios de Azure Site Recovery.
6. En los almacenes de Recovery Services, haga clic en Información general > ContosoVMVault >
+Replicar.
7. En Origen, seleccione Azure.
8. En Ubicación de origen, seleccione la región de Azure de origen donde se ejecutan actualmente sus máquinas
virtuales.
9. Seleccione el modelo de implementación de Resource Manager. A continuación, seleccione la suscripción de
origen y el grupo de recursos de origen.
10. Seleccione Aceptar para guardar la configuración.
Habilite la replicación de máquinas virtuales de Azure y comience a copiar los datos
Site Recovery recupera una lista de las máquinas virtuales asociadas a la suscripción y el grupo de recursos.
1. En el paso siguiente, seleccione la máquina virtual que desee mover y, después, seleccione Aceptar.
2. En Configuración, haga clic en Recuperación ante desastres.
3. En Configurar recuperación ante desastres > Región de destino, seleccione la región de destino en la
que quiere realizar la replicación.
4. Para este tutorial, acepte los valores predeterminados.
5. Seleccione Habilitar replicación. Este paso inicia un trabajo para habilitar la replicación de la máquina
virtual.
Move
En los pasos siguientes se muestra cómo realizar el traslado a la región de destino.
1. Vaya al almacén. En Configuración > Elementos replicados, seleccione la máquina virtual y luego seleccione
Conmutación por error.
2. En Conmutación por error, seleccione Más reciente.
3. Seleccione Apague la máquina antes de comenzar con la conmutación por error. A continuación, Site
Recovery intentará apagar la máquina virtual de origen antes de desencadenar la conmutación por error. La
conmutación por error continúa aunque se produzca un error de cierre. Puede seguir el progreso de la
conmutación por error en la página Trabajos.
4. Una vez finalizado el trabajo, compruebe que la máquina virtual aparece en la región de Azure de destino como
se esperaba.
Discard (Descartar)
En caso de que haya comprobado la máquina virtual que se ha trasladado y tenga que cambiarla al punto de
conmutación por error o desee volver a un punto anterior, en los Elementos replicados, haga clic con el botón de
derecho para seleccionar la máquina virtual y cambie el punto de recuperación. Este paso le ofrece la opción de
especificar un punto de recuperación diferente y conmutar por error a ese mismo.
Confirmación
Una vez que haya comprobado la máquina virtual que se ha trasladado y esté preparado para confirmar el cambio
, en loselementos replicados, seleccione con el botón derecho la máquina virtual y confirme. Esto finaliza el
proceso de traslado a la región de destino. Espere hasta que el trabajo de confirmación finalice.
Limpieza
Los pasos siguientes le guiarán por el proceso de limpieza de la región de origen, así como de los recursos
relacionados que se usaron para el traslado.
Para todos los recursos que se usaron para el traslado:
Vaya a la máquina virtual. Seleccione Deshabilitar replicación. Este paso detiene el proceso de copiar los
datos para la máquina virtual.
IMPORTANT
Es importante realizar este paso para evitar cargos por replicación de Azure Site Recovery.
Si no piensa volver a usar ninguno de los recursos de origen, siga estos pasos adicionales:
1. Elimine todos los recursos de red pertinentes en la región de origen que identificó en los requisitos previos.
2. Elimine la cuenta de almacenamiento correspondiente en la región de origen.
Pasos siguientes
En este tutorial ha trasladado una máquina virtual de Azure a otra región de Azure. Ahora puede configurar la
opción de recuperación ante desastres para la máquina virtual que ha trasladado.
Configurar la recuperación ante desastres después de la migración
Traslado de máquinas virtuales de Azure a zonas de
disponibilidad
Availability Zones de Azure ayuda a proteger las aplicaciones y los datos de errores del centro de datos. Cada zona
de disponibilidad consta de uno o varios centros de datos equipados con alimentación, refrigeración y redes
independientes. Para garantizar la resistencia, hay tres zonas independientes como mínimo en todas las regiones
habilitadas. La separación física de Availability Zones dentro de una región ayuda a proteger las aplicaciones y los
datos frente a los errores del centro de datos. Con la incorporación de Availability Zones, ofrecemos un acuerdo de
nivel de servicio (SLA) que garantiza un tiempo de actividad de las máquinas virtuales (VM ) del 99,99 %.
Availability Zones se admite en regiones exclusivas, tal como se indica en ¿Qué es Availability Zones en Azure?.
En un escenario en el que se implementan las máquinas virtuales como de instancia única en una región específica
y desea mejorar la disponibilidad trasladándolas a una instancia de Availability Zones, puede hacerlo con Azure Site
Recovery. Esta acción se puede categorizar más adelante en:
Traslado de máquinas virtuales de instancia única a Availability Zones en una región de destino
Traslado de máquinas virtuales de un conjunto de disponibilidad en Availability Zones de región de destino
IMPORTANT
Actualmente Azure Site Recovery permite trasladar máquinas virtuales de una región a otra, pero no admite el traslado
dentro de una misma región.
Comprobación de los requisitos previos

Compruebe si la región de destino es compatible con Availability Zones. Compruebe que su opción de
combinación de región de origen y región de destino se admite. Tome una decisión informada sobre la
región de destino.
Asegúrese de entender la arquitectura y los componentes del escenario.
Revise las limitaciones y los requisitos de compatibilidad.
Compruebe los permisos de la cuenta Si acaba de crear su cuenta de Azure gratis, ya es el administrador de
la suscripción. Si no es administrador de la suscripción, solicite al administrador que le asigne los permisos
que necesita. Para habilitar la replicación para una máquina virtual y finalmente copiar los datos al destino
mediante Azure Site Recovery, debe tener:
1. Permisos para crear una máquina virtual en recursos de Azure. El rol integrado Colaborador de la
máquina virtual tiene estos permisos, que incluyen:
Permiso para crear una máquina virtual en el grupo de recursos seleccionado.
Permiso para crear una máquina virtual en la red virtual seleccionada
Permiso para escribir en la cuenta de almacenamiento seleccionada
2. Permisos para administrar las tareas de Azure Site Recovery. El rol Colaborador de Site Recovery
tiene todos los permisos necesarios para administrar las acciones de Site Recovery en un almacén de
Recovery Services.
Preparación de las máquinas virtuales de origen
1. Las máquinas virtuales deben usar discos administrados si desea trasladarlas a una instancia de Availability
Zones mediante Site Recovery. Puede convertir VM Windows existentes que usan discos no administrados
para que usen discos administrados. Siga los pasos en Conversión de una máquina virtual Windows con
discos no administrados a discos administrados. Asegúrese de que el conjunto de disponibilidad esté
configurado como administrado.
2. Asegúrese de que todos los certificados raíz más recientes estén presentes en las máquinas virtuales de
Azure que quiera trasladar. Si los últimos certificados raíz no están presentes, la copia de datos en la región
de destino no se puede habilitar debido a las restricciones de seguridad.
3. Para las máquinas virtuales de Windows, instale las actualizaciones de Windows más recientes en la
máquina virtual, de modo que todos los certificados raíz de confianza estén en ella. En un entorno
desconectado, siga los procesos estándar de actualización de certificados y de Windows Update en su
organización.
4. En las máquinas virtuales Linux, para obtener los últimos certificados raíz de confianza y la lista de
revocación de certificados en la máquina virtual, siga las instrucciones proporcionadas por su distribuidor de
Linux.
5. Asegúrese de que no utiliza ningún proxy de autenticación para controlar la conectividad de red de las
máquinas virtuales que quiere trasladar.
6. Si la máquina virtual que está intentando trasladar no tiene acceso a Internet y utiliza un proxy de firewall
para controlar el acceso de salida, compruebe los requisitos en Configuración de la conectividad de red
saliente.
7. Identifique el diseño de la red de origen y los recursos que utiliza actualmente para la verificación, incluidos
equilibradores de carga, grupos de seguridad de red y dirección IP pública.
Preparación de la región de destino

1. Compruebe que su suscripción de Azure permite crear máquinas virtuales en la región de destino que se
usa para la recuperación ante desastres. Si es preciso, póngase en contacto con el soporte técnico para
habilitar la cuota necesaria.
2. Asegúrese de que su suscripción tiene suficientes recursos para admitir máquinas virtuales con tamaños que
se correspondan con las máquinas virtuales de origen. Si usa Site Recovery para copiar datos en el destino,
elige el mismo tamaño para la máquina virtual de destino o el más cercano posible.
3. Cree un recurso de destino para cada componente identificado en el diseño de la red de origen. Esta acción
garantiza que, tras la migración a la región de destino, las máquinas virtuales tengan toda la funcionalidad y
características que tenían en el origen.
NOTE
Azure Site Recovery automáticamente detecta y crea una red virtual y una cuenta de almacenamiento al habilitar la
replicación para la máquina virtual de origen. También puede crear previamente estos recursos y asignar a la máquina
virtual como parte del paso para habilitar la replicación. Pero para cualquier otro recurso, como se menciona
posteriormente, es necesario crearlo manualmente en la región de destino.
En los siguientes documentos se explica cómo crear los recursos de red más utilizados y que considere más
relevantes, en función de la configuración de la máquina virtual de origen.
Dirección IP pública
Para cualquier otro componente de red, consulte la documentación de red.
IMPORTANT
Asegúrese de usar un equilibrador de carga con redundancia de zona en el destino. Puede leer más en Standard Load
Balancer y Availability Zones.
4. Si desea probar la configuración antes de realizar la migración a la región de destino, cree manualmente una
red sin producción en la región de destino. Se recomienda este enfoque porque provoca interferencias
mínimas con el entorno de producción.
Habilitar replicación
Los siguientes pasos le guiarán al usar Azure Site Recovery para permitir la replicación de datos en la región de
destino, antes de que finalmente los traslade a Availability Zones.
NOTE
Estos pasos son para una sola máquina virtual. Puede ampliar los mismos para varias máquinas virtuales. Vaya al almacén de
Recovery Services, seleccione + Replicar y seleccione las máquinas virtuales pertinentes de forma conjunta.
1. En Azure Portal, seleccione Máquinas virtuales y seleccione la máquina virtual que desea trasladar a
Availability Zones.
2. En Operaciones, seleccione Recuperación ante desastres.
3. En Configurar recuperación ante desastres > Región de destino, seleccione la región de destino en la
que quiere realizar la replicación. Asegúrese de que esta región admita Availability Zones.
4. Seleccione Siguiente: Configuración avanzada.

5. Elija los valores adecuados para la suscripción de destino, el grupo de recursos de la máquina virtual de
destino y la red virtual.
6. En la sección Disponibilidad, elija la instancia de Availability Zones a la que desea trasladar la máquina
virtual.
NOTE
Si no ve la opción para el conjunto de disponibilidad o la instancia de Availability Zones, compruebe que se cumplen
los requisitos previos y que se ha completado la preparación de las máquinas virtuales de origen.
7. Seleccione Habilitar replicación. Esta acción inicia un trabajo para habilitar la replicación de la máquina
virtual.
Comprobación de la configuración
Cuando haya finalizado el trabajo de replicación, puede comprobar el estado de replicación, modificar la
configuración de replicación y probar la implementación.
1. En el menú de la máquina virtual, seleccione Recuperación ante desastres.
2. Puede comprobar el estado de replicación, los puntos de recuperación que se han creado y las regiones de
origen y destino en el mapa.
Pruebe la configuración.
2. Seleccione el icono Conmutación por error de prueba.
3. En Conmutación por error de prueba, seleccione el punto de recuperación que usar para la conmutación
por error:
Procesado más recientemente: error de la VM en el último punto de recuperación procesado por el
servicio Site Recovery. Se muestra la marca de tiempo. Con esta opción, no se emplea tiempo en el
procesamiento de datos, por lo que se proporciona un objetivo de tiempo de recuperación (RTO ) bajo.
Más reciente coherente con la aplicación: esta opción conmuta por error todas las VM en el punto de
recuperación más reciente coherente con la aplicación. Se muestra la marca de tiempo.
Personalizado: seleccione un punto de recuperación.
4. Seleccione la red virtual de Azure de destino de prueba a la que desea mover las máquinas virtuales de
Azure para probar la configuración.
IMPORTANT
Le recomendamos que utilice una red de máquinas virtuales de Azure independiente para la conmutación por error de
prueba y no la red de producción de la región de destino a la que desea trasladar las máquinas virtuales.
5. Para comenzar a probar el traslado, seleccione Aceptar. Para realizar el seguimiento del progreso,
seleccione la máquina virtual para abrir sus propiedades. También puede seleccionar el trabajo
Conmutación por error de prueba en el nombre del almacén > Configuración > Trabajos > Trabajos
de Site Recovery.
6. Una vez finalizada la conmutación por error, la VM de Azure de réplica aparece en Azure Portal > Virtual
Machines. Asegúrese de que la máquina virtual está en funcionamiento, tiene el tamaño adecuado y está
conectada a la red apropiada.
7. Si desea eliminar la máquina virtual creada como parte de la prueba del traslado, seleccione Limpiar
conmutación por error de prueba en el elemento replicado. En Notas, registre y guarde las
observaciones asociadas a la prueba.
Realización del traslado a la región de destino y confirmar

2. Seleccione el icono Conmutación por error.
3. En Conmutación por error, seleccione Más reciente.
4. Seleccione Apague la máquina antes de comenzar con la conmutación por error. A continuación, Site
Recovery intentará apagar la máquina virtual de origen antes de desencadenar la conmutación por error. La
conmutación por error continúa aunque se produzca un error de cierre. Puede seguir el progreso de la
conmutación por error en la página Trabajos.
5. Una vez finalizado el trabajo, compruebe que la máquina virtual aparece en la región de Azure de destino como
se esperaba.
6. En Elementos replicados, haga clic con el botón derecho en la máquina virtual > Confirmar. Esto finaliza el
proceso de traslado a la región de destino. Espere hasta que el trabajo de confirmación finalice.
Descarte de los recursos en la región de origen

Vaya a la máquina virtual. Seleccione Deshabilitar replicación. Esta acción detiene el proceso de copiar los datos
para la máquina virtual.
IMPORTANT
Realice el paso anterior para evitar cargos por la replicación de Site Recovery tras el traslado. La configuración de replicación
de origen se limpia automáticamente. Tenga en cuenta que la extensión de Site Recovery que se instala como parte de la
replicación no se ha eliminado y tiene que quitarse manualmente.
Pasos siguientes
En este tutorial ha aumentado la disponibilidad de una máquina virtual de Azure al trasladarla a un conjunto de
disponibilidad o instancia de Availability Zones. Ya puede establecer la opción de recuperación ante desastres para
la máquina virtual que ha trasladado.
Configurar la recuperación ante desastres después de la migración
Migración desde Amazon Web Services (AWS) y
otras plataformas a Managed Disks en Azure
Puede cargar archivos de VHD desde AWS o soluciones de virtualización locales en Azure para crear máquinas
virtuales que aprovechen las ventajas de Managed Disks. Azure Managed Disks elimina la necesidad de
administrar las cuentas de almacenamiento para las VM IaaS de Azure. Solo tiene que especificar el tipo (premium
o estándar) y el tamaño del disco que necesita, y Azure lo crea y administra automáticamente.
Puede cargar VHD generalizados o especializados.
VHD generalizado: elimina toda la información personal de la cuenta mediante Sysprep.
VHD especializado: mantiene las cuentas de usuario, las aplicaciones y otros datos de estado de la máquina
virtual original.
IMPORTANT
Antes de cargar los VHD en Azure, debe consultar Preparación de un VHD o un VHDX de Windows antes de cargarlo en
Azure
ESCENARIO DOCUMENTACIÓN
Tiene instancias EC2 de AWS existentes que le gustaría migrar Migración de una máquina virtual de Amazon Web Services
a máquinas virtuales de Azure mediante discos administrados. (AWS) a Azure
Tiene una máquina virtual de otra plataforma de virtualización Carga de un VHD generalizado y uso de este para crear una
que le gustaría usar como imagen para crear varias máquinas nueva máquina virtual en Azure
virtuales de Azure.
Cuenta con una VM personalizada de forma exclusiva que Carga de un VHD especializado en Azure y creación de una
quisiera recrear en Azure. máquina nueva
Información general de Managed Disks

Azure Managed Disks simplifica la administración de VM al eliminar la necesidad de administrar cuentas de
almacenamiento. Managed Disks también aprovecha las ventajas de la mejor confiabilidad de las VM en un
conjunto de disponibilidad. Esto garantiza que los discos de las distintas VM de un conjunto de disponibilidad
estarán lo suficientemente aislados entre sí como para evitar un único punto de error. Coloca automáticamente
discos de distintas VM en un conjunto de disponibilidad en unidades de escalado de almacenamiento diferentes
(marcas de tiempo), lo que limita el impacto de errores únicos de unidad de escalado de almacenamiento
generados debido a errores de hardware y software. En virtud de sus necesidades, puede elegir entre cuatro tipos
de opciones de almacenamiento. Para información acerca de los tipos de disco disponibles, consulte nuestro
artículo Selección de un tipo de disco.
Planeación de la migración a Managed Disks

Esta sección puede ayudarlo a tomar la mejor decisión sobre los tipos de discos y VM.
Si planea migrar de discos no administrados a discos administrados, debe saber que los usuarios con el rol
Colaborador de máquina virtual no podrán cambiar el tamaño de la máquina virtual (como podían hacer antes de
la conversión). El motivo es que las máquinas virtuales con discos administrados requieren que el usuario tenga el
permiso de escritura/discos/Microsoft.Compute para los discos del sistema operativo.
Location
Elija una ubicación donde Azure Managed Disks esté disponible. Si va a migrar a Managed Disks Premium,
asegúrese que Premium Storage también está disponible en la región a la que planea migrar. Consulte Servicios
de Azure por región para obtener información actualizada sobre las ubicaciones disponibles.
Tamaños de VM
Si va a migrar a Managed Disks Premium, debe actualizar el tamaño de la VM a un tamaño compatible con
Premium Storage disponible en la región donde se ubica la VM. Revise los tamaños de VM compatibles con
Premium Storage. Las especificaciones de tamaño de las máquinas virtuales de Azure se muestran en Tamaños de
máquinas virtuales. Repase las características de rendimiento de las máquinas virtuales que trabajan con Premium
Storage y elija el tamaño de máquina virtual que se mejor se ajuste a su carga de trabajo. Procure que haya
suficiente ancho de banda disponible en la máquina virtual para dirigir el tráfico de disco.
Tamaños de disco
Managed Disks Premium
Hay siete tipos de Managed Disks premium que se pueden usar con la máquina virtual y cada uno de ellos tiene
sus límites específicos de rendimiento y E/S por segundo. Tenga presentes estos límites a la hora de elegir el tipo
de disco Premium para la VM según las necesidades de capacidad, rendimiento, escalabilidad y cargas máximas de
la aplicación.
TIPO DE
DISCOS
PREMIUM P4 P6 P10 P15 P20 P30 P40 P50
Tamaño 32 GB 64 GB 128 GB 256 GB 512 GB 1.024 GB 2048 GB 4095 GB

del (1 TB) (2 TB) (4 TB)
disco
IOPS por 120 240 500 1100 2300 5000 7500 7500
disco
Rendimie 25 MB 50 MB 100 MB 125 MB 150 MB 200 MB 250 MB 250 MB

nto de por por por por por por por por
disco segundo segundo segundo segundo segundo segundo segundo segundo
Discos administrados Estándar

Hay siete tipos de Managed Disks estándar que se pueden usar con la máquina virtual. Cada uno de ellos tiene
una capacidad distinta, pero los mismos límites de rendimiento y E/S por segundo. Elija el tipo de disco
administrado Estándar según las necesidades de capacidad de la aplicación.
TIPO DE
DISCO
ESTÁNDAR
S4 S6 S10 S15 S20 S30 S40 S50
Tamaño 30 64 128 256 512 1.024 GB 2048 GB 4095 GB

del GB GB GB GB GB (1 TB) (2 TB) (4 TB)
disco
TIPO DE
DISCO
ESTÁNDAR
S4 S6 S10 S15 S20 S30 S40 S50
IOPS por 500 500 500 500 500 500 500 500
disco
Rendimie 60 MB 60 MB 60 MB 60 MB 60 MB 60 MB 60 MB 60 MB
nto de por por por por por por por por
disco. segundo segundo segundo segundo segundo segundo segundo segundo
Directiva de almacenamiento en caché de disco

Managed Disks Premium
De forma predeterminada, la directiva de almacenamiento en caché de los discos es Solo lectura para todos los
discos de datos Premium y Lectura y Escritura para el disco de sistema operativo Premium conectado a la
máquina virtual. Recomendamos esta opción de configuración para lograr el rendimiento óptimo de E/S de la
aplicación. Para discos de datos de solo escritura o de gran cantidad de escritura (por ejemplo, archivos de registro
de SQL Server), deshabilite el almacenamiento en caché de disco para lograr un mejor rendimiento de la
aplicación.
Precios
Revise el precio de Managed Disks. Los precios de Managed Disks Premium son iguales que los de Unmanaged
Disks Premium. Sin embargo, los precios de Managed Disks Estándar son distintos a los de los Unmanaged Disks
Estándar.
Pasos siguientes
Antes de cargar los VHD en Azure, debe consultar Preparación de un VHD o un VHDX de Windows antes de
cargarlo en Azure
Carga de un VHD generalizado y su uso para crear
máquinas virtuales nuevas en Azure
En este artículo se explica cómo usar PowerShell para cargar un VHD de una máquina virtual generalizada en
Azure, crear una imagen a partir del VHD y crear una máquina virtual nueva desde esa imagen. Puede cargar
un VHD exportado de una herramienta de visualización local o desde otra nube. Usar Managed Disks para la
nueva VM simplifica la administración de la VM y proporciona una mejor disponibilidad cuando la VM se
encuentra en un conjunto de disponibilidad.
Para un script de ejemplo, consulte Script de ejemplo para cargar un disco duro virtual en Azure y crear una
máquina virtual nueva.
Antes de empezar
Antes de cargar los VHD en Azure, debe consultar Preparación de un VHD o un VHDX de Windows antes
de cargarlo en Azure.
Revise Plan for the migration to Managed Disks (Planeación de la migración a Managed Disks) antes de
comenzar la migración a Managed Disks.
Generalización de la VM de origen mediante Sysprep

Entre otras características, Sysprep elimina toda la información personal de la cuenta y prepara, entre otras
cosas, la máquina para usarse como imagen. Para más información acerca de Sysprep, consulte la Introducción
a Sysprep.
Asegúrese de que los roles de servidor que se ejecutan en la máquina sean compatibles con Sysprep. Para más
información, consulte Sysprep Support for Server Roles(Compatibilidad de Sysprep con roles de servidor).
IMPORTANT
Si tiene pensado ejecutar Sysprep antes de cargar el VHD en Azure por primera vez, asegúrese de que tiene preparada la
máquina virtual.
1. Inicie sesión en la máquina virtual de Windows.

2. Abra una ventana del símbolo del sistema como administrador. Cambie el directorio a
%windir%\system32\sysprep, y, después, ejecute sysprep.exe .
asegúrese de que la casilla Generalizar está seleccionada.
Carga del VHD en la cuenta de almacenamiento

Ahora puede cargar un disco duro virtual directamente en un disco administrado. Para obtener instrucciones al
respecto, consulte Carga de un disco duro virtual en Azure mediante Azure PowerShell.
Creación de una imagen administrada desde el VHD cargado

Cree una imagen administrada desde el disco administrado del SO generalizado. Reemplace los valores
siguientes por su propia información.
Primero, configure algunos parámetros:

Cree la imagen con el VHD del SO generalizado.
$imageConfig = New-AzImageConfig `
-Location $location
$imageConfig = Set-AzImageOsDisk `
-Image $imageConfig `
-OsType Windows `
-OsState Generalized `
-BlobUri $urlOfUploadedImageVhd `
-DiskSizeGB 20
New-AzImage `
-ImageName $imageName `
-Image $imageConfig

Ahora que tiene una imagen, puede crear una o varias VM desde la imagen. En este ejemplo se crea una
máquina virtual denominada myVM a partir de myImage, en myResourceGroup.
New-AzVm `
-Name "myVM" `
-ImageName $imageName `
-SecurityGroupName "myNSG" `
-PublicIpAddressName "myPIP" `
-OpenPorts 3389
Pasos siguientes
Inicie sesión en la nueva máquina virtual. Para más información, consulte Conexión a una máquina virtual de
Azure donde se ejecuta Windows Server e inicio de sesión en ella.
Migración de una máquina virtual Windows de
Amazon Web Services (AWS) a una máquina virtual
Azure
Si va a evaluar las máquinas virtuales de Azure para hospedar las cargas de trabajo, puede exportar una instancia
existente de la máquina virtual Windows de Amazon Web Services (AWS ) EC2 y cargar el disco duro virtual
(VHD ) en Azure. Una vez cargado el disco duro virtual, puede crear una nueva máquina virtual en Azure desde el
disco duro virtual.
En este artículo se cubre la migración de una sola máquina virtual de AWS a Azure. Si quiere migrar máquinas
virtuales de AWS a Azure en escala, consulte Migrar máquinas virtuales de Amazon Web Services (AWS ) a Azure
con Azure Site Recovery.
Puede cargar VHD generalizados y especializados en Azure. Todos requieren la preparación de la máquina virtual
antes de la exportación desde AWS.
VHD generalizado: Se ha quitado toda la información de cuenta personal con Sysprep de un VHD
generalizado. Si tiene previsto usar VHD como una imagen desde la que crear nuevas VM, debe:
Preparación de una máquina virtual Windows.
Generalice la máquina virtual mediante Sysprep.
VHD especializado: un disco duro virtual especializado mantiene las cuentas de usuario, las aplicaciones y
otros datos de estado de la máquina virtual original. Si tiene previsto usar el VHD como está para crear una
nueva VM, asegúrese de completar los pasos siguientes.
Preparar de un VHD de Windows para cargar en Azure. No generalice la VM mediante Sysprep.
Quite todas las herramientas de virtualización de invitado y los agentes instalados en la VM (es decir,
herramientas de VMware).
Asegúrese de que la VM se configura para extraer su dirección IP y la configuración de DNS a través de
DHCP. Esto garantiza que el servidor obtiene una dirección IP dentro de la red virtual cuando se inicia.
Exportación y descarga del disco duro virtual

Exporte la instancia de EC2 a un disco duro virtual de un cubo de Amazon S3. Siga los pasos del artículo Exporting
an Instance as a VM Using VM Import/Export (Exportación de una instancia como una máquina virtual con la
importación/exportación de máquinas virtuales) de la documentación de Amazon y ejecute el comando create-
instance-export-task para exportar la instancia de EC2 a un archivo VHD.
El archivo VHD exportado se guarda en el cubo de Amazon S3 que haya especificado. La sintaxis básica para
exportar el disco duro virtual se encuentra justo debajo, solo tiene que reemplazar el texto del marcador de
posición entre <corchetes angulares> por su información.
aws ec2 create-instance-export-task --instance-id <instanceID> --target-environment Microsoft \

--export-to-s3-task DiskImageFormat=VHD,ContainerFormat=ova,S3Bucket=<bucket>,S3Prefix=<prefix>
Una vez exportado el disco duro virtual, siga las instrucciones de How Do I Download an Object from an S3
Bucket? (Descarga de objetos desde un cubo de S3) para descargar el archivo VHD desde el cubo de S3.
IMPORTANT
Por la descarga del disco duro virtual, AWS cobra una tarifa de transferencia de datos. Consulte Precios de Amazon S3 para
más información.
Pasos siguientes
Ahora puede cargar el disco duro virtual en Azure y crear una máquina virtual.
Si ha ejecutado Sysprep en el origen para la generalización antes de exportarlo, consulte el artículo de Carga
de un disco duro virtual generalizado y creación de máquinas virtuales en Azure con él
Si no ejecutó Sysprep antes de la exportación, se considera que el disco duro virtual es especializado; consulte
el artículo de Carga de un disco duro virtual especializado en Azure y creación de máquinas virtuales con él
2 minutes to read
Migración compatible con la plataforma de recursos
de IaaS del modelo clásico al de Azure Resource
Manager
En este artículo se describe la forma de migrar recursos de infraestructura como servicio (IaaS ) de los modelos
de implementación clásicos a Resource Manager y detalla cómo conectar los recursos de los dos modelos de
implementación que coexisten en su suscripción mediante el uso de puertas de enlace de sitio a sitio de red
virtual. Se puede leer más información sobre características y ventajas de Azure Resource Manager.
Objetivo para la migración

Resource Manager permite implementar aplicaciones complejas a través de plantillas, configura las máquinas
virtuales mediante extensiones de máquina virtual e incorpora la administración de acceso y el etiquetado.
Azure Resource Manager incluye una implementación escalable en paralelo para máquinas virtuales en
conjuntos de disponibilidad. El nuevo modelo de implementación también proporciona administración del ciclo
de vida para procesos, redes y almacenamiento por separado. Por último, también se centra en habilitar la
seguridad de forma predeterminada con la aplicación de máquinas virtuales en una red virtual.
En Azure Resource Manager, se admiten casi todas las características del modelo de implementación clásica en
cuanto a proceso, red y almacenamiento. Para sacar partido de las nuevas funcionalidades de Resource
Manager, puede migrar las implementaciones existentes desde el modelo de implementación clásica.
Recursos que se admiten en la migración

Estos recursos de IaaS clásicos se admiten durante la migración
Virtual Machines
Cloud Services con Virtual Machines
Cuentas de almacenamiento
Virtual Networks
Puertas de enlace de VPN
Puertas de enlace de ExpressRoute (en la misma suscripción que solo Virtual Network)
Tablas de ruta
Direcciones IP reservadas
Ámbitos admitidos de la migración

Hay cuatro maneras diferentes de completar la migración de los recursos de proceso, red y almacenamiento:
Migración de máquinas virtuales (NO en una red virtual)
Migración de máquinas virtuales (en una red virtual)
Migración de cuentas de almacenamiento
Migración de recursos sin asociar
Migración de máquinas virtuales (NO en una red virtual)
En el modelo de implementación de Resource Manager, la seguridad de las aplicaciones se aplica de forma
predeterminada. En este modelo, todas las máquinas virtuales deben estar en una red virtual. La plataforma
Azure reinicia ( Stop , Deallocate y Start ) las máquinas virtuales como parte de la migración. Hay dos
opciones para las redes virtuales a las que se Virtual Machines va a migrar:
Puede solicitar que la plataforma cree una red virtual y migrar la máquina virtual a ella.
Puede migrar la máquina virtual a una red virtual existente en Resource Manager.
NOTE
En este ámbito de migración, es posible que haya un determinado período durante la migración en que no se permitan las
operaciones en el plano de administración y el plano de datos.
Migración de máquinas virtuales (en una red virtual)

Para la mayoría de las configuraciones de máquina virtual, solo se migran los metadatos entre el modelo de
implementación clásica y el de Resource Manager. Las máquinas virtuales subyacentes se ejecutan en el mismo
hardware, en la misma red y con el mismo almacenamiento. Es posible que haya un determinado período
durante la migración en que no se permitan las operaciones en el plano de administración. Sin embargo, el
plano de datos sigue funcionando. Es decir, las aplicaciones que se ejecutan en máquinas virtuales (clásicas) no
experimentan tiempo de inactividad durante la migración.
Actualmente no se admiten las siguientes configuraciones. Si se agrega compatibilidad en el futuro, es posible
que algunas máquinas virtuales en esta configuración sufran tiempos de inactividad (pasen por operaciones de
detención, desasignación y reinicio).
Tiene más de un conjunto de disponibilidad en un único servicio en la nube.
Tiene uno o varios conjuntos de disponibilidad y máquinas virtuales que no están en un conjunto de
disponibilidad en un único servicio en la nube.
NOTE
En este ámbito de migración, es posible que haya un determinado período durante la migración en que no se permitan las
operaciones en el plano de administración. Para determinadas configuraciones descritas anteriormente, se producirá un
tiempo de inactividad en el plano de datos.
Migración de cuentas de almacenamiento

Para lograr una migración sin problemas, se pueden implementar máquinas virtuales de Resource Manager en
una cuenta de almacenamiento clásico. Con esta funcionalidad, los recursos de procesos y redes se pueden y se
deben migrar con independencia de las cuentas de almacenamiento. Una vez migradas las máquinas virtuales y
la red virtual, se deben migrar las cuentas de almacenamiento para completar el proceso de migración.
Si la cuenta de almacenamiento no tiene ningún disco o datos de Máquinas virtuales asociados y solo tiene
blobs, archivos, tablas y colas, entonces la migración a Azure Resource Manager se puede realizar como una
migración independiente sin dependencias.
NOTE
El modelo de implementación de Resource Manager carece del concepto de discos e imágenes de la implementación
clásica. Cuando se migra la cuenta de almacenamiento, los discos e imágenes de la implementación clásica no están visibles
en la pila de Resource Manager pero los discos duros virtuales de respaldo permanecen en la cuenta de almacenamiento.
En las capturas de pantalla siguientes se muestra cómo actualizar una cuenta de almacenamiento de la
implementación clásica a una cuenta de almacenamiento de Azure Resource Manager mediante Azure Portal:
2. Vaya a la cuenta de almacenamiento.
3. En la sección Configuración, haga clic en Migrar a ARM.
4. Haga clic en Validar para determinar la viabilidad de la migración.
5. Si la validación es correcta, haga clic en Preparar para crear una cuenta de almacenamiento migrada.
6. Escriba Sí para confirmar la migración y haga clic en Confirmar para finalizar la migración.
Migración de recursos sin asociar
Las cuentas de almacenamiento que no tengan discos o datos de máquinas virtuales asociados se puede migrar
de forma independiente.
Los grupos de seguridad de red, las tablas de ruta y las IP reservadas que no están conectadas a ninguna
máquina virtual y red virtual también se pueden migrar de forma independiente.
Configuraciones y características no admitidas

Actualmente no se admiten ciertas características y configuraciones, aunque en las siguientes secciones
encontrará una descripción con nuestras recomendaciones.
Características no admitidas
Actualmente no se admiten las siguientes características. Opcionalmente, puede quitar estas configuraciones,
migrar las máquinas virtuales y después volver a habilitar dichas configuraciones en el modelo de
implementación de Resource Manager.
PROVEEDOR DE RECURSOS CARACTERÍSTICA RECOMENDACIÓN
Proceso Discos de máquinas virtuales no Los blobs de VHD que hay detrás de
asociados. estos discos se migrarán cuando lo
haga la cuenta de almacenamiento
Proceso Imágenes de máquina virtual. Los blobs de VHD que hay detrás de
estos discos se migrarán cuando lo
haga la cuenta de almacenamiento
Red ACL de puntos de conexión. Quitar las ACL de los puntos de

conexión y vuelva a intentar la
migración.
Red Application Gateway Quite Application Gateway antes de

comenzar la migración y, después,
vuelva a crearlo una vez que la
migración se complete.
PROVEEDOR DE RECURSOS CARACTERÍSTICA RECOMENDACIÓN
Red Redes virtuales que usan el Migrar Virtual Network a Resource

emparejamiento de VNET. Manager y, después, del mismo nivel.
Más información acerca del
emparejamiento de VNET.
Configuraciones no admitidas
Actualmente no se admiten las siguientes configuraciones.
SERVICIO CONFIGURACIÓN RECOMENDACIÓN
Resource Manager Control de acceso basado en rol Puesto que el identificador URI de los
(RBAC) para recursos clásicos recursos se modifica después de la
migración, se recomienda planear las
actualizaciones de directiva del control
de acceso basado en rol que deben
producirse después de la migración.
Proceso Varias subredes asociadas con una Actualice la configuración de subred

máquina virtual para que solo haga referencia a una
subred. Puede que para ello sea
necesario quitar una NIC secundaria
(que hace referencia a otra subred) de
la máquina virtual y asociarla de nuevo
una vez finalizada la migración.
Proceso Máquinas virtuales que pertenecen a Opcionalmente, puede eliminar la

una red virtual, pero no tienen una máquina virtual.
subred explícita asignada
Proceso Máquinas virtuales que tienen alertas, Se efectúa la migración y se descartan

directivas de escalado automático estos valores. Es muy recomendable
evaluar el entorno antes de realizar la
migración. Como alternativa, puede
reconfigurar los valores de las alertas
una vez completada la migración.
Proceso Extensiones XML de máquina virtual ya que no es compatible. Se

(BGInfo 1.*, depurador de Visual recomienda que quite estas
Studio, Web Deploy y depuración extensiones de la máquina virtual para
remota) continuar la migración o se quitarán
automáticamente durante el proceso.
Proceso Diagnóstico de arranque con Deshabilite la característica de

Almacenamiento premium diagnósticos de arranque para las
máquinas virtuales antes de continuar
con la migración. Puede volver a
habilitar los diagnósticos de arranque
en la pila de Resource Manager una
vez completada la migración. Además,
se deben eliminar los blobs que se
utilizan para los registros de captura de
pantalla y de serie, por lo que ya no se
cobra por los blobs.
Proceso Servicios en la nube que contienen Actualmente no se admite.

roles web y de trabajo
Proceso Servicios en la nube que contienen más Actualmente no se admite. Mueva

de un conjunto de disponibilidad o Virtual Machines al mismo conjunto de
varios. disponibilidad antes de la migración.
Proceso VM con extensión de Azure Security Azure Security Center instala

Center automáticamente las extensiones en
las máquinas virtuales para supervisar
la seguridad y generar alertas. Si está
habilitada la directiva de Azure Security
Center en la suscripción, estas
extensiones se suelen instalar
automáticamente. Para migrar las
máquinas virtuales, deshabilite la
directiva de Security Center en la
suscripción; esta operación quitará la
extensión de supervisión de Security
Center de las máquinas virtuales.
Proceso VM con extensión de instantánea o Estas extensiones se instalan en una

copia de seguridad máquina virtual configurada con el
servicio Azure Backup. Mientras no se
admita la migración de estas máquinas
virtuales, siga las instrucciones que se
indican aquí para conservar las copias
de seguridad que se realizaron antes
de la migración.
Red Redes virtuales que contienen Actualmente no se admite. Mueva los

máquinas virtuales y roles web y de roles web y de trabajo a su propia
trabajo Virtual Network antes de la migración.
Una vez que se migra Virtual Network
clásica, Virtual Network de Azure
Resource Manager se puede emparejar
con Virtual Network clásica para lograr
una configuración similar a la anterior.
Red Circuitos ExpressRoute clásicos Actualmente no se admite. Estos

circuitos se deben migrar a Azure
Resource Manager antes de comenzar
la migración de IaaS. Para obtener más
información, consulte la transición de
los circuitos ExpressRoute del modelo
de implementación clásica al modelo
de implementación de Resource
Manager.
Azure App Service Redes virtuales que contienen Actualmente no se admite.

entornos de App Service
HDInsight de Azure Redes virtuales que contienen servicios Actualmente no se admite.

de HDInsight
Dynamics Lifecycle Services Redes virtuales que contienen Actualmente no se admite.

máquinas virtuales administradas por
Dynamics Lifecycle Services
Azure AD Domain Services Redes virtuales que contienen servicios Actualmente no se admite.
de dominio de Azure AD
Azure API Management Redes virtuales que contienen Actualmente no se admite. Para migrar
implementaciones de Azure API la red virtual de IaaS, cambie la red
Management virtual de la implementación de API
Management que no sea una
operación de tiempo de inactividad.
Pasos siguientes
Profundización técnica en la migración compatible con la plataforma de la implementación clásica a la de
Planning for migration of IaaS resources from classic to Azure Resource Manager (Planificación de la
migración de recursos de IaaS del modelo clásico a Azure Resource Manager)
Migración de recursos de IaaS de la implementación clásica a Resource Manager con Azure PowerShell
Migración de recursos de IaaS de la implementación clásica a Azure Resource Manager con la CLI de Azure
Migración de VPN Gateway (clásico) a Resource Manager
Migración de circuitos ExpressRoute y las redes virtuales asociadas del modelo de implementación clásica a
Resource Manager
Herramientas de la comunidad para ayudar con la migración de recursos de IaaS del modelo de
implementación clásica a Azure Resource Manager
Revisión de los errores más comunes en la migración
Revisión de las preguntas más frecuentes acerca de cómo migrar recursos de IaaS de la versión clásica a
Profundización técnica en la migración compatible
con la plataforma de la implementación clásica a la
de Azure Resource Manager
Profundicemos en la migración desde el modelo de implementación clásica de Azure hasta el modelo de

implementación de Azure Resource Manager. Nos centramos en los recursos en un nivel de recursos y función
que le ayudarán a comprender cómo la Plataforma de Azure migra los recursos entre los dos modelos de
implementación. Para obtener más información, lea el artículo de anuncio de servicio: Migración compatible con
la plataforma de recursos de IaaS del modelo clásico al de Azure Resource Manager.
Migración de recursos IaaS del modelo de implementación clásica a

En primer lugar, es importante conocer la diferencia entre operaciones del plano de datos y del plano de
administración en los recursos de infraestructura como servicio (IaaS ).
El plano de administración o control describe las llamadas que entran en el plano de administración o control,
o la API para modificar los recursos. Por ejemplo, operaciones como crear una máquina virtual, reiniciar una
máquina virtual y actualizar una red virtual con una nueva subred administran los recursos en ejecución. No
afectan directamente a la conexión con las máquinas virtuales.
El plano de datos (aplicación) describe el runtime de la aplicación en sí e incluye la interacción con instancias
que no pasan por la API de Azure. Por ejemplo, el acceso a su sitio web o la extracción de datos desde una
instancia de SQL Server o un servidor MongoDB en ejecución se consideran interacciones de aplicación o del
plano de datos. Otros ejemplos incluyen la copia de un blob de una cuenta de almacenamiento y el acceso a
una dirección IP pública para usar el Protocolo de escritorio remoto (RDP ) o Secure Shell (SSH) en la
máquina virtual. Estas operaciones mantienen la aplicación en ejecución en procesos, redes y almacenamiento.
El plano de datos es el mismo entre el modelo de implementación clásica y las pilas de Resource Manager. La
diferencia es que durante el proceso de migración, Microsoft traslada la representación de los recursos del
modelo de implementación clásica al de la pila de Resource Manager. Como consecuencia, es preciso que use las
nuevas herramientas, API y SDK para administrar los recursos de la pila de Resource Manager.
NOTE
En algunos escenarios de migración, la plataforma Azure se detiene, desasigna y reinicia las máquinas virtuales. Esto
provoca que un breve período de inactividad en el plano de datos.
Experiencia de migración
Antes de empezar la migración:
Asegúrese de que los recursos que desea migrar no usan las características o configuraciones no admitidas.
Normalmente, la plataforma detecta estos problemas y genera un error.
Si tiene máquinas virtuales que no están en una red virtual, estás se detienen y se desasignan, pero ello forma
parte de la operación de preparación. Si no desea perder la dirección IP pública, considere la posibilidad de
reservar la dirección IP antes de desencadenar la operación de preparación. Si las máquinas virtuales están en
una red virtual, no se detienen ni se desasignan.
Planee la migración fuera del horario de actividad, para dar cabida a errores inesperados que surjan durante
ella.
Descargue la configuración actual de las máquinas virtuales mediante PowerShell, los comandos de la interfaz
de la línea de comandos (CLI) o las API de REST para facilitar la validación una vez que finalice el paso de
preparación.
Actualice los scripts de automatización y operacionalización para controlar el modelo de implementación con
Resource Manager antes de iniciar la migración. También tiene la opción de realizar las operaciones GET
cuando los recursos se encuentren en el estado preparado.
Evalúe las directivas de control de acceso basado en rol (RBAC ) configuradas en los recursos de IaaS en el
modelo de implementación clásica y defina un plan para cuando se haya completado la migración.
El flujo de trabajo de la migración es el siguiente:
NOTE
Las operaciones que se describen en las siguientes secciones son todas idempotentes. Si tiene un problema que no sea que
alguna función no se admite o un error de configuración, vuelva a intentar la operación de preparación, anulación o
confirmación. Azure vuelve a intentar la acción.
Validación
La operación de validación es el primer paso del proceso de migración. El objetivo de este paso es analizar el
estado de los recursos que desea migrar en el modelo de implementación clásica. La operación evalúa si los
recursos son capaces de realizar la migración (éxito o error).
Se seleccionará la red virtual o el servicio en la nube (si no está en una red virtual) que se quiere validar para la
migración. Si el recurso no es capaz de realizar la migración, Azure enumera los motivos.
Comprobaciones que no se realizan en la operación de validación
La operación de validación solo analiza el estado de los recursos en el modelo de implementación clásica. En este
modelo, es posible comprobar todos los errores y escenarios no admitidos debido a diversas configuraciones. Sin
embargo, no es posible comprobar todos los problemas que podría imponer la pila de Azure Resource Manager
sobre los recursos durante la migración. Estos problemas solo se comprueban cuando los recursos llevan a cabo
la transformación en el siguiente paso de la migración (la operación de preparación). En la tabla siguiente se
enumeran todos los problemas que no se comprueban en la operación de validación:
COMPROBACIONES DE RED QUE NO SE REALIZAN EN LA OPERACIÓN DE VALIDACIÓN
Que una red virtual tiene puertas de enlace de ER y de VPN.
Que una conexión de un puerta de enlace de red virtual se encuentra en estado de desconexión.
Todos los circuitos de ER se han migrado previamente a la pila de Azure Resource Manager.
Comprobaciones de la cuota Azure Resource Manager en los recursos de red. Por ejemplo: dirección IP pública estática,
direcciones IP públicas dinámicas, equilibrador de carga, grupos de seguridad de red, tablas de rutas e interfaces de red.
Todas las reglas del equilibrador de carga son válidas en las implementaciones y la red virtual.
Conflictos de direcciones IP privadas entre máquinas virtuales con desasignación detenida de la misma red virtual.
Preparación
La operación de preparación es el secundo paso del proceso de migración. El objetivo de este paso es simular la
transformación de los recursos de IaaS desde el modelo de implementación clásica a los recursos de Resource
Manager. Además, la operación de preparación presenta ambos en paralelo para facilitar su visualización.
NOTE
Los recursos del modelo de implementación clásica no se modifican en este paso. Es un paso seguro de ejecutar si se
prueba la migración.
Se seleccionará la red virtual o el servicio en la nube (si no es una red virtual) que se quiere preparar para la
migración.
Si el recurso no se puede migrar, Azure detiene el proceso de migración y muestra el motivo de error de la
operación de preparación.
Si el recurso se puede migrar, Azure bloquea las operaciones en el plano de administración de los recursos en
proceso de migración. Por ejemplo, no puede agregar un disco de datos a una máquina virtual en proceso de
migración.
Luego, Azure comienza la migración de los metadatos del modelo de implementación clásica al de Resource
Manager para los recursos que se migran.
Una vez que se completa la operación de preparación, tiene la opción de visualizar los recursos tanto en el
modelo de implementación clásica como en el de Resource Manager. Para cada servicio en la nube en el modelo
de implementación clásica, la plataforma de Azure crea un nombre de grupo de recursos con el patrón
cloud-service-name>-Migrated .
NOTE
No es posible seleccionar el nombre de un grupo de recursos creado para los recursos migrados (es decir, "-Migrated"). Sin
embargo, una vez que se haya completado la migración, puede usar la característica de movimiento de Azure Resource
Manager para mover recursos al grupo de recursos que desee. Para obtener más información, consulte Traslado de los
recursos a un nuevo grupo de recursos o a una nueva suscripción.
Las dos capturas de pantalla siguientes muestran el resultado después de una operación de preparación correcta.
La primera muestra un grupo de recursos que contiene el servicio en la nube original. La segunda muestra el
nuevo grupo de recursos "-Migrated" que contiene los recursos equivalentes de Azure Resource Manager.
Esta es una vista en segundo plano de los recursos tras finalizar la fase de preparación. Tenga en cuenta que el
recurso del plano de datos es el mismo. Se representa en el plano de administración (modelo de implementación
clásica) y el plano de control (Resource Manager).
NOTE
Las máquinas virtuales que no se encuentran en una red virtual en el modelo de implementación clásica se detienen y se
desasignan en esta fase de la migración.
Comprobación (manual o mediante scripts)

En este paso de la comprobación, tiene la opción de usar la configuración que descargó antes para validar si la
migración parece correcta. Como alternativa, puede iniciar sesión en el portal y revisar las propiedades y los
recursos para validar que la migración de los metadatos es correcta.
Si están migrando una red virtual, no se reinicia la mayoría de la configuración de las máquinas virtuales. En el
caso de las aplicaciones de dichas máquinas virtuales, puede validar si la aplicación sigue en ejecución.
Puede probar los scripts operacionales y de supervisión y automatización para ver si las máquinas virtuales
funcionan de forma esperada y si los scripts actualizados funcionan correctamente. Tenga en cuenta que solo se
admiten operaciones GET cuando los recursos se encuentran en el estado preparado.
No hay ninguna ventana de tiempo establecida antes del cual deba confirmar la migración. Puede mantenerse el
tiempo que desee en este estado. No obstante, el plano de administración queda bloqueado para estos recursos
hasta que lleve a cabo la operación de anulación o confirmación.
Si ve algún problema, siempre puede anular la migración y volver al modelo de implementación clásica. Si lo
hace, Azure abrirá las operaciones del plano de administración en los recursos para que pueda reanudar las
operaciones normales en esas máquinas virtuales en el modelo de implementación clásica.
Anulación
Este paso es opcional si desea revertir los cambios realizados en el modelo de implementación clásica y detener
la migración. Esta operación elimina los metadatos de Resource Manager (creados en el paso de preparación) en
los recursos.
NOTE
Esta operación no se puede realizar una vez que se ha desencadenado la operación de confirmación.
Confirmación
Después de finalizar la validación, puede confirmar la migración. Los recursos no aparecen en el modelo de
implementación clásica y solo están disponibles en el modelo de implementación con Resource Manager. Los
recursos migrados solo se pueden administrar en el nuevo portal.
NOTE
Se trata de una operación idempotente. Si se produce un error, vuelva a intentar la operación. Si sigue sin poder
completarla, cree un vale de soporte o publique una entrada con la etiqueta "ClassicIaaSMigration" en el foro de máquinas
virtuales.
Diagrama de flujo de migración
Este es un diagrama de flujo que muestra cómo realizar la migración:
Traslación del modelo de implementación clásica a los recursos de

Resource Manager
Puede encontrar las representaciones del modelo de implementación clásica y de Resource Manager de los
recursos en la tabla siguiente. Actualmente no se admiten otras funciones y recursos.
REPRESENTACIÓN DE RESOURCE
REPRESENTACIÓN CLÁSICA MANAGER NOTAS
Nombre del servicio en la nube Nombre DNS Durante la migración, se crea un nuevo
grupo de recursos para cada servicio en
la nube con el patrón de nomenclatura
<cloudservicename>-migrated . Este
grupo de recursos contiene todos los
recursos. El nombre del servicio en la
nube se convierte en un nombre DNS
que está asociado a la dirección IP
pública.
Máquina virtual Máquina virtual Las propiedades específicas de la

máquina virtual se migran sin cambios.
Determinada información de osProfile,
como el nombre de equipo, no se
almacena en el modelo de
implementación clásica y permanece
vacía después de la migración.
Recursos de disco conectados a la Implícitos discos conectados a la Los discos no se modelan como
máquina virtual máquina virtual recursos de nivel superior en el modelo
de implementación de Resource
Manager. Se migran como discos
implícitos en la máquina virtual.
Actualmente, se admiten solo los discos
que están conectados a una VM. Las
máquinas virtuales de Resource
Manager ya pueden usar ahora cuentas
de almacenamiento en el modelo de
implementación clásica, los que permite
que los discos se migren fácilmente sin
actualizaciones.
Extensiones de máquina virtual Extensiones de máquina virtual Todas las extensiones de recursos,
excepto las extensiones XML, se migran
desde el modelo de implementación
clásica.
Certificados de la máquina virtual Certificados en Azure Key Vault Si un servicio en la nube contiene
certificados de servicio, la migración
crea un nuevo almacén de claves de
Azure por cada servicio en la nube y
mueve los certificados a dicho almacén.
Las máquinas virtuales se actualizan
para hacer referencia a los certificados
del almacén de claves.
No elimine el almacén de claves, ya que

la máquina virtual puede ponerse en
estado de error.
Configuración de WinRM Configuración de WinRM en osProfile La configuración de Administración

remota de Windows se traslada tal cual
como parte de la migración.
Propiedad de conjunto de Recurso de conjunto de disponibilidad La especificación del conjunto de

disponibilidad disponibilidad es una propiedad de la
máquina virtual en el modelo de
implementación clásica. Los conjuntos
de disponibilidad se convierten en un
recurso de nivel superior como parte
de la migración. Las siguientes
configuraciones no son compatibles:
varios conjuntos de disponibilidad por
servicio en la nube o uno o varios
conjuntos de disponibilidad junto con
máquinas virtuales que no están en
ningún conjunto de disponibilidad de
un servicio en la nube.
Configuración de red en una máquina Interfaz de red principal La configuración de red en una
virtual máquina virtual se representa como el
recurso de la interfaz de red principal
después de la migración. En el caso de
las máquinas virtuales que no están en
una red virtual, la dirección IP interna
cambia durante la migración.
Varias interfaces de red en una Interfaces de red Si una máquina virtual tiene varias
máquina virtual interfaces de red asociadas, cada una
de ellas se convierte en un recurso de
nivel superior como parte de la
migración, junto con todas las
propiedades.
Conjunto de punto de conexión de Equilibrador de carga En el modelo de implementación

carga equilibrada clásica, la plataforma asignaba un
equilibrador de carga implícito para
cada servicio en la nube. Durante la
migración, se crea un nuevo recurso de
equilibrador de carga, y el conjunto de
puntos de conexión con equilibrio de
carga se convierte en reglas de
Reglas NAT de entrada Reglas NAT de entrada Los puntos de conexión de entrada
definidos en la VM se convierten en
reglas de traducción de direcciones de
red de entrada en el equilibrador de
carga durante la migración.
Dirección VIP Dirección IP pública con nombre DNS La dirección IP virtual se convierte en
una dirección IP pública y se asocia con
el equilibrador de carga. Solo se puede
migrar una dirección IP virtual si hay un
punto de conexión de entrada asignado
a ella.
Virtual network Virtual network La red virtual se migra con todas sus
propiedades al modelo de
Se crea un nuevo grupo de recursos
con el nombre -migrated .
Direcciones IP reservadas Dirección IP pública con método de Las direcciones IP reservadas asociadas
asignación estático con el equilibrador de carga se migran
junto con la migración del servicio en la
nube o de la máquina virtual.
Actualmente, no se admite la migración
de direcciones IP reservadas no
asociadas.
Dirección IP pública por máquina Dirección IP pública con método de La dirección IP pública asociada a la
virtual asignación dinámico máquina virtual se convierte como un
recurso de dirección IP público con el
método de asignación establecido en
estático.
Grupos de seguridad de red Grupos de seguridad de red Los grupos de seguridad de red
asociados a una subred se clonan como
parte de la migración al modelo de
El grupo de seguridad de red no se
quita en el modelo de implementación
clásica durante la migración. Sin
embargo, las operaciones de plano de
administración para el grupo de
seguridad de red se bloquean cuando
la migración está en curso.
Servidores DNS Servidores DNS Los servidores DNS asociados con la

máquina virtual o una red virtual se
migran como parte de la migración de
recursos correspondiente junto con
todas las propiedades.
Rutas definidas por el usuario Rutas definidas por el usuario Las rutas definidas por el usuario
asociadas a una subred se clonan como
parte de la migración al modelo de
Las rutas definidas por el usuario no se
quitan en el modelo de implementación
clásica durante la migración. Las
operaciones de plano de administración
para las rutas definidas por el usuario
se bloquean cuando la migración está
en curso.
Propiedad de reenvío de IP en una Propiedad de reenvío de IP en la NIC La propiedad de reenvío de IP en una

configuración de red de máquina máquina virtual se convierte en una
virtual propiedad en la interfaz de red durante
la migración.
Equilibrador de carga con varias IP Equilibrador de carga con varios Todas las direcciones IP públicas
recursos de dirección IP pública asociadas con el equilibrador de carga
se convierten en un recurso de
dirección IP pública y se asocian con el
equilibrador de carga después de la
migración.
Nombres DNS internos en la máquina Nombres DNS internos en la NIC Durante la migración, se migran los
virtual sufijos DNS internos para la máquina
virtual a una propiedad de solo lectura
denominada
"InternalDomainNameSuffix" en la NIC.
El sufijo no cambia después de la
migración y la resolución de la máquina
virtual debería seguir funcionando
como antes.
Puerta de enlace de red virtual Puerta de enlace de red virtual Las propiedades de la puerta de enlace
de red virtual se migran sin cambios. La
VIP asociada a la puerta de enlace no
cambia.
Sitio de red local Puerta de enlace de red local Las propiedades del sitio de red local se
migran sin cambios a un nuevo recurso
denominado puerta de enlace de red
local. Esto representa prefijos de
direcciones locales y la IP de la puerta
de enlace remota.
Referencias de conexiones Conexión Las referencias de conectividad entre la

puerta de enlace y el sitio de red local
en la configuración de red se
representan mediante un recurso
nuevo denominado Connection. Todas
las propiedades de referencia de
conectividad de los archivos de
configuración de red se copian sin
cambios al recurso Connection. La
conectividad entre redes virtuales en el
modelo de implementación clásica se
logra mediante la creación de dos
túneles IPsec a sitios de red local que
representan las redes virtuales. Esto se
transforma en un tipo de conexión de
red virtual a red virtual en el modelo de
Resource Manager sin necesidad de
puertas de enlace de red local.
Cambios en la automatización y las herramientas después de la

migración
Como parte de la migración de los recursos desde el modelo de implementación clásica al de Resource Manager,
es preciso actualizar la automatización o las herramientas existentes para asegurarse de que siguen funcionando
después de la migración.
Pasos siguientes
Información general sobre la migración compatible con la plataforma de recursos de IaaS desde el modelo de
Resource Manager
Planificación de la migración de recursos de IaaS del
modelo clásico a Azure Resource Manager
Aunque Azure Resource Manager ofrece muchas características increíbles, es fundamental planear la trayectoria
de migración para asegurarse de que el proceso se desarrolla con facilidad. Dedicar tiempo a la planificación
garantizará que no se planteen problemas al ejecutar las actividades de migración.
NOTE
El equipo de asesoramiento al cliente de Azure y los arquitectos de soluciones en la nube han contribuido
significativamente en la elaboración de la guía siguiente en colaboración con los clientes en relación con la migración de
entornos grandes. Habida cuenta de que este documento estará sujeto a actualizaciones continuas a medida que surjan
nuevos patrones de éxito, resulta conveniente consultarlo de vez en cuando para ver si existen nuevas recomendaciones.
La trayectoria de migración consta de cuatro fases generales:
Plan
Consideraciones técnicas y compromisos
En función de la envergadura de los requisitos técnicos, de las zonas geográficas y de las prácticas operativas,
debería tener en cuenta lo siguiente:
1. ¿Por qué le interesa contar con Azure Resource Manager en su organización? ¿Por qué motivos empresariales
desea realizar una migración?
2. ¿Cuáles son las razones técnicas para disponer de Azure Resource Manager? ¿De qué servicios adicionales de
Azure desearía beneficiarse, si procede?
¿
3. Qué aplicación o conjuntos de máquinas virtuales se incluyen en la migración?
4. ¿Qué escenarios son compatibles con la API de migración? Revise las configuraciones y características no
admitidas.
5. ¿Los equipos operativos ahora admiten aplicaciones y máquinas virtuales tanto en el modelo clásico como en
Azure Resource Manager?
¿
6. Cómo Azure Resource Manager cambia los procesos de creación de informes, la supervisión, la
administración y la implementación de máquinas virtuales, en caso de que sea posible? ¿Es necesario
actualizar los scripts de implementación?
7. ¿Cuál es el plan de comunicaciones para avisar a las partes interesadas (usuarios finales, propietarios de
aplicaciones y propietarios de infraestructuras)?
8. Según la complejidad del entorno, ¿debe haber un período de mantenimiento durante el cual la aplicación no
está disponible para los usuarios finales y los propietarios de aplicaciones? En su caso, ¿durante cuánto
tiempo?
9. ¿Cuál es el plan de aprendizaje para asegurarse de que las partes interesadas conocen y dominan Azure
Resource Manager?
10. ¿Cuál es el plan de administración de programas o de proyectos para la migración?
11. ¿Cuáles son las escalas de tiempo para la migración de Azure Resource Manager y para otros mapas de rutas
tecnológicos relacionados? ¿Están perfectamente alineados?
Patrones de éxito
Los clientes de éxito disponen de planes detallados en los que se abordan, documentan y administran las
preguntas anteriores. Asegúrese de que los planes de migración se comunican de forma amplia a los
patrocinadores y a las partes interesadas. Adquiera conocimientos sobre las opciones de migración; se
recomienda leer este documento de migración a continuación.
Información general sobre la migración compatible con la plataforma de recursos de IaaS desde el modelo
de implementación clásica a Azure Resource Manager
Revisión de las preguntas más frecuentes acerca de cómo migrar recursos de IaaS del modelo de
Errores que hay que evitar
Errores de planificación. Los pasos tecnológicos de esta migración se han comprobado y el resultado es
predecible.
En todos los escenarios se tendrá en cuenta la suposición de que la plataforma admite la API de migración.
Leer las configuraciones y características no admitidas para saber qué escenarios se admiten.
Ausencia de planificación de interrupciones potenciales de la aplicación para los usuarios finales. Planee
suficiente búfer para advertir a los usuarios finales del tiempo durante el cual la aplicación posiblemente no
estará disponible.
Análisis de laboratorio
Replicación de un entorno y realización de una migración de prueba
NOTE
La replicación exacta de un entorno existente se ejecuta mediante una herramienta en la que ha contribuido la comunidad
que no es compatible oficialmente con el Soporte técnico de Microsoft. Por lo tanto, se trata de un paso opcional, pero es
la mejor manera de encontrar los problemas sin tocar los entornos de producción. Si no tiene la opción de usar una
herramienta en la que ha contribuido la comunidad, lea la recomendación Simulacro de validación, preparación y anulación
a continuación.
Realizar un análisis de laboratorio de un escenario exacto (proceso, red y almacenamiento) es la mejor forma de
asegurar una migración sin problemas. Esto le ayudará a garantizar:
Que dispone para el análisis de un laboratorio totalmente independiente o de un entorno existente que no
sea de producción. Se recomienda un laboratorio completamente independiente que se pueda migrar
varias veces y que se pueda modificar de forma destructiva. A continuación se indican los scripts para
recopilar e hidratar metadatos de suscripciones reales.
Es una buena idea crear el laboratorio en una suscripción independiente. El motivo es que el laboratorio
se desactivará varias veces, por lo que disponer de una suscripción aislada e independiente reducirá la
posibilidad de eliminar por error cualquier elemento real.
Esto puede realizarse con la herramienta AsmMetadataParser. Aquí puede encontrar más información
sobre esta herramienta.
Patrones de éxito
A continuación se indican problemas detectados en muchas de las migraciones más grandes. No se trata de una
lista exhaustiva, por lo que debe remitirse a Configuraciones y características no admitidas para más detalles.
Puede encontrarse o no con estos problemas técnicos, pero, de plantearse, podrá tener una experiencia más
fluida si los soluciona antes de intentar realizar la migración.
Realice un simulacro de validación, preparación y anulación: se trata quizás del paso más
importante para asegurarse de que la migración del modelo clásico a Azure Resource Manager se realiza
correctamente. La API de migración se compone de tres pasos principales: validación, preparación y
confirmación. Con la validación se leerá el estado del entorno clásico y se devolverá un resultado de todos
los problemas. Sin embargo, como algunos problemas pueden existir en la pila de Azure Resource
Manager, la validación puede no detectarlo todo. En el paso siguiente del proceso de migración, la
preparación ayudará a exponer los problemas detectados. Con la preparación, todos los metadatos se
moverán del modelo clásico a Azure Resource Manager, pero no se confirmará la migración ni se
eliminará ni modificará nada del modelo clásico. El simulacro conlleva preparar la migración y después
anular (no confirmar) la preparación de la migración. El objetivo del simulacro de validación, preparación
y anulación es que todos los metadatos se encuentren en la pila de Azure Resource Manager, para
después examinarlos (mediante programación o en el portal) y verificar que todo se ha migrado
correctamente, pero también con el propósito de abordar los problemas técnicos. También le permitirá
hacerse una idea de la duración de la migración, a fin de que pueda planear el tiempo de inactividad. Un
simulacro de validación, preparación y anulación no causa ningún tiempo de inactividad al usuario, por lo
que no produce ninguna interrupción del uso de la aplicación.
Será necesario solucionar los puntos siguientes antes del simulacro, aunque, en caso de omitirlos, la
prueba de simulacro eliminará con seguridad estos pasos de preparación. Durante la migración
empresarial, se ha observado que el simulacro es una forma segura e inestimable de garantizar la
preparación de la migración.
Cuando la preparación se encuentra en ejecución, el plano de control (operaciones de administración
de Azure) se bloquearán en toda la red virtual, por lo que no se puede realizar ninguna modificación
en los metadatos de máquinas virtuales durante el proceso de validación, preparación y anulación. No
obstante, en caso contrario, ninguna función de la aplicación (Escritorio remoto, uso de máquina
virtual, etc.) se verá afectada. Los usuarios de las máquinas virtuales no sabrán que el simulacro está en
ejecución.
VPN y circuitos ExpressRoute. Actualmente no se pueden migrar las puertas de enlace de
ExpressRoute con vínculos de autorización sin tiempos de inactividad. Para consultar una solución
alternativa, vea Migración de circuitos ExpressRoute y las redes virtuales asociadas del modelo de
implementación clásica a Resource Manager.
Extensiones de máquina virtual: las extensiones de máquina virtual posiblemente son uno de los
obstáculos más importantes para migrar las máquinas virtuales en ejecución. La corrección de
extensiones de máquina virtual puede tardar de 1 a 2 días, por lo que es necesario realizar la planificación
teniendo esto en cuenta. Se precisa de un agente de Azure operativo para informar del estado de las
extensiones de las máquinas virtuales en ejecución. Si se notifica un estado incorrecto de una máquina
virtual en ejecución, la migración se detendrá. El agente no necesita estar operativo para habilitar la
migración, pero, si existen extensiones en la máquina virtual, se necesitará un agente operativo Y una
conectividad saliente a Internet con DNS para que la migración progrese.
Si se pierde la conectividad con un servidor DNS durante la migración, hay que eliminar todas las
extensiones de máquina virtual , excepto BGInfo versión 1. *, de todas las máquinas virtuales antes de
preparar la migración y, después, volver a agregarlas a la máquina virtual después de la migración de
Azure Resource Manager. Esto solo se aplica a las máquinas virtuales en ejecución. Si las
máquinas virtuales se detienen cuando están desasignadas, no es necesario eliminar las extensiones
de máquina virtual.
NOTE
Muchas extensiones, como la supervisión de Azure Diagnósticos y Security Center, se reinstalarán
automáticamente después de la migración, por lo que su eliminación no plantea ningún problema.
Además, asegúrese de que los Grupos de seguridad de red no restringen el acceso saliente a
Internet. Esto puede suceder con algunas configuraciones de Grupos de seguridad de red. El
acceso saliente a Internet, y DNS, resulta necesario para migrar las extensiones de máquina virtual
a Azure Resource Manager.
Existen dos versiones de la extensión BGInfo, que se denominan versiones 1 y 2.
Si la máquina virtual usa la extensión de la versión 1 de BGInfo, dicha extensión se puede dejar
tal cual. La API de migración omite esta extensión. La extensión BGInfo puede agregarse
después de la migración.
Si la máquina virtual usa la extensión de la versión 2 de BGInfo basada en JSON, significa que
la máquina virtual se creó mediante Azure Portal. La API de migración incluye esta extensión en
la migración a Azure Resource Manager, siempre que el agente funcione y tenga acceso saliente
a Internet (y DNS ).
Opción de corrección 1. Si sabe que las máquinas virtuales no tendrán acceso saliente a Internet,
un servicio DSN activo y agentes de Azure operativos en las máquinas virtuales, desinstale las
extensiones de máquina virtual como parte de la migración antes de la fase de preparación y luego
reinstálelas después de la migración.
Opción de corrección 2. Si las extensiones de máquina virtual plantean un gran obstáculo, otra
opción consiste en apagar o desasignar todas las máquinas virtuales antes de la migración. Migre
las máquinas virtuales desasignadas y luego reinícielas en Azure Resource Manager. Aquí la
ventaja es que las extensiones de máquina virtual se migrarán. El inconveniente es que todas las IP
virtuales públicas se perderán, algo que no tiene sentido, ya que las máquinas virtuales se
apagarán con un impacto mucho mayor en las aplicaciones operativas.
NOTE
Si se configura una directiva de Azure Security Center con respecto a las máquinas virtuales en ejecución
que se van a migrar, es necesario detener dicha directiva de seguridad antes de quitar las extensiones, ya
que, de lo contrario, la extensión de supervisión de seguridad se reinstalará automáticamente en la
máquina virtual después de quitarla.
Conjuntos de disponibilidad: para migrar una red virtual (vNet) a Azure Resource Manager, todas las
máquinas virtuales contenidas en la implementación clásica, es decir, el servicio en la nube, deben
encontrarse en un conjunto de disponibilidad, o bien ninguna máquina virtual debe pertenecer a ningún
conjunto de disponibilidad. Azure Resource Manager no admite que haya más de un conjunto de
disponibilidad en el servicio en la nube y, de ser así, la migración se detendrá. Además, no puede haber
algunas máquinas virtuales en un conjunto de disponibilidad, y algunas máquinas virtuales no están en
un conjunto de disponibilidad. Para solucionar esta cuestión, será necesario corregir o reorganizar el
servicio en la nube. Tenga esto en cuenta para realizar la planificación, ya que esta operación puede llevar
bastante tiempo.
Implementaciones de roles web y roles de trabajo: Cloud Services con roles web y roles de trabajo
no se puede migrar a Azure Resource Manager. Para migrar el contenido de los roles web y de trabajo,
deberá migrar el propio código al App Services PaaS más reciente (este tema queda fuera del ámbito de
este documento). Si quiere dejar los roles web o de trabajo tal cual, pero migrar las máquinas virtuales
clásicas al modelo de implementación de Resource Manager, primero se deben quitar los roles web o de
trabajo de la red virtual antes de que se pueda iniciar la migración. Una solución típica consiste en
trasladar las instancias de rol web o de trabajo a una red virtual clásica independiente que también esté
vinculada a un circuito ExpressRoute. En el caso de reimplementación anterior, cree una red virtual clásica
nueva, mueva los roles web y los roles de trabajo a esa nueva red virtual o reimpleméntelos ahí y luego
elimine las implementaciones de la red virtual que se va a migrar. No se requiere ningún cambio de
código. La nueva funcionalidad Emparejamiento de red virtual se puede utilizar para emparejar la red
virtual clásica que contiene los roles web y los roles de trabajo con otras redes virtuales de la misma
región de Azure, como la red virtual que se va a migrar (después de que termine la migración de la
red virtual, ya que las máquinas virtuales emparejadas no se pueden migrar), a fin de ofrecer las
mismas funcionalidades sin perder rendimiento y sin penalizaciones de latencia o ancho de banda.
Gracias a la adición del Emparejamiento de red virtual, las implementaciones de roles web y roles de
trabajo ahora pueden mitigarse con facilidad y no bloquean la migración a Azure Resource Manager.
Cuotas de Azure Resource Manager: las regiones de Azure tienen cuota y límites independientes para
el modelo clásico y Azure Resource Manager. Aunque en un escenario de migración no se utiliza ningún
hardware nuevo (se están cambiando las máquinas virtuales existentes del modelo clásico a Azure
Resource Manager ) , todavía es necesario que haya cuotas de Azure Resource Manager con capacidad
suficiente para poder iniciar la migración. A continuación, se especifican los límites principales con los que
se han detectado problemas. Abra un vale de soporte sobre cuotas para aumentar los límites.
NOTE
Estos límites hay que aumentarlos en la misma región a la que se va a migrar el entorno actual.
Interfaces de red
Direcciones IP públicas
Direcciones IP públicas estáticas
Núcleos
Tablas de ruta
Puede comprobar las cuotas actuales de Azure Resource Manager mediante los comandos
siguientes con la última versión de Azure PowerShell.
Compute (núcleos y conjuntos de disponibilidad )
Get-AzVMUsage -Location <azure-region>
Red (redes virtuales, direcciones IP públicas estáticas, direcciones IP públicas, grupos de seguridad
de red, interfaces, equilibradores de carga y tablas de rutas)
Get-AzUsage /subscriptions/<subscription-id>/providers/Microsoft.Network/locations/<azure-
region> -ApiVersion 2016-03-30 | Format-Table
Almacenamiento (cuenta de almacenamiento )
Get-AzStorageUsage
Límites de la API de Azure Resource Manager: si tiene un entorno lo suficientemente grande (por
ejemplo, más de 400 máquinas virtuales en una red virtual), podría alcanzar los límites predeterminados
de escritura de la API (actualmente 1200 writes/hour ) en Azure Resource Manager. Antes de iniciar la
migración, debe presentar un vale de soporte para aumentar este límite en la suscripción.
Estado de máquina virtual de tiempo de espera de aprovisionamiento agotado: si alguna
máquina virtual presenta el estado provisioning timed out , es necesario resolver este problema antes de
la migración. La única manera de hacerlo es que el tiempo de inactividad, mediante el
desaprovisionamiento y el reaprovisionamiento de la máquina virtual, es decir, eliminarla, conservar el
disco y volver a crearla.
Estado de máquina virtual RoleStateUnknown: si la migración se detiene debido a un mensaje de
error role state unknown , inspeccione la máquina virtual en el portal y asegúrese de que está en
ejecución. Este error suele desaparecer por sí solo (no se precisa de ninguna corrección) transcurridos
unos minutos, suele ser de carácter transitorio y suele detectarse durante las operaciones start , stop y
restart de una máquina virtual. Práctica recomendada: vuelva a intentar la migración después de
unos minutos.
El clúster de Fabric no existe : en algunos casos, determinadas máquinas virtuales no se pueden migrar
por distintas razones poco comunes. Uno de estos casos conocidos se da si la máquina virtual se ha
creado recientemente (durante la última semana más o menos) y ha iniciado un clúster de Azure que aún
no está equipado para cargas de trabajo de Azure Resource Manager. Obtendrá un error que indica
fabric cluster does not exist y, en este caso, la máquina virtual no se puede migrar. Normalmente,
basta con esperar un par de día para que este problema concreto se resuelva, ya que el clúster no tardará
en estar habilitado para Azure Resource Manager. Sin embargo, una solución inmediata consiste en
stop-deallocate la máquina virtual, continuar después con la migración e iniciar la copia de seguridad de
la máquina virtual en Azure Resource Manager después de la migración.
No use métodos abreviados y omita las migraciones del simulacro de validación, preparación y anulación.
La mayoría de los problemas potenciales, si no todos, se detectarán durante los pasos del simulacro de
validación, preparación y anulación.
Migración
Ahora está listo porque ha trabajado con los problemas conocidos en su entorno.
Para las migraciones reales, conviene tener en cuenta lo siguiente:
1. Planifique y programe la red virtual (unidad más pequeña de migración) con mayor prioridad. Céntrese
primero en las redes virtuales sencillas y continúe después con las más complicadas.
2. La mayoría de los clientes tendrán entornos de producción y de no producción. Programe la producción en
última instancia.
3. (OPCIONAL ) Programe un tiempo de inactividad por mantenimiento con una gran cantidad de búfer en
caso de que surjan problemas inesperados.
4. Comuníquese con los equipos de soporte y póngase de acuerdo con ellos en caso de que surjan problemas.
Patrones de éxito
La orientación técnica de la sección Análisis de laboratorio se debe tener en cuenta y abordar antes de realizar la
migración real. Con las pruebas oportunas, la migración realmente no es ningún evento. Para entornos de
producción, puede resultar útil contar con soporte técnico adicional, como un asociado de Microsoft de
confianza o Microsoft Premier Services.
El hecho de no realizar las pruebas completas puede generar problemas y retrasos en la migración.
Después de la migración
Ahora que ya está en Azure Resource Manager, maximice la plataforma. Lea la información general de Azure
Resource Manager para obtener información sobre otras ventajas.
Puntos que se deben tener en cuenta:
Agrupe la migración con otras actividades. La mayoría de los clientes optan por una ventana de
mantenimiento de la aplicación. En su caso, podría usar este tiempo de inactividad para habilitar otras
funcionalidades de Azure Resource Manager, como el cifrado y la migración a Managed Disks.
Revise los motivos técnicos y empresariales para migrar a Azure Resource Manager; habilite los servicios
adicionales disponibles solo en Azure Resource Manager que sean aplicables a su entorno.
Modernice el entorno con servicios PaaS.
Patrones de éxito
Determine qué servicios desea habilitar en Azure Resource Manager. Muchos clientes encuentran atractivos los
siguientes para sus entornos de Azure:
Control de acceso basado en rol.
Plantillas de Azure Resource Manager para una implementación más sencilla y controlada.
Etiquetas.
Control de actividad
Directivas de Azure
Recuerde por qué ha iniciado esta trayectoria de migración del modelo clásico a Azure Resource Manager.
¿Cuáles eran los objetivos empresariales originales? ¿Ha conseguido el objetivo empresarial?
Pasos siguientes
Información general sobre la migración compatible con la plataforma de recursos de IaaS desde el modelo
de implementación clásica a Azure Resource Manager
Resource Manager
Migración de recursos de IaaS de la implementación
clásica a la de Resource Manager con Azure
PowerShell
En estos pasos se describe cómo utilizar los comandos de Azure PowerShell para migrar los recursos de
infraestructura como servicio (IaaS ) desde el modelo de implementación clásica al modelo de implementación
de Azure Resource Manager.
Si lo desea, también puede migrar recursos mediante la interfaz de línea de comandos de Azure (CLI de Azure).
Lea el artículo Migración compatible con la plataforma de recursos de IaaS del modelo clásico a Azure
Resource Managerpara obtener información sobre los escenarios de migración que se admiten.
Si quiere obtener instrucciones detalladas y ver un tutorial de migración, consulte Profundización técnica en
la migración compatible con la plataforma de la implementación clásica a la de Azure Resource Manager.
Este es un diagrama de flujo para identificar el orden en que tienen que ejecutarse durante un proceso de migración.
Paso 1: Planear la migración

Estos son algunos de los procedimientos recomendados a la hora de evaluar la migración de recursos de IaaS
desde el modelo clásico a Resource Manager:
Lea el artículo sobre qué características y configuraciones se admiten y cuáles no. Si tiene máquinas virtuales
que usan configuraciones o características no admitidas, se recomienda esperar a que se anuncie dicha
compatibilidad. De manera alternativa, si se ajusta a sus necesidades, quite esa característica o salga de esa
configuración para habilitar la migración.
Si tiene actualmente scripts automatizados que implementan la infraestructura y las aplicaciones, intente
crear una configuración de prueba similar usando esos scripts para la migración. También puede configurar
entornos de ejemplo mediante el Portal de Azure.
IMPORTANT
Las puertas de enlace de aplicaciones no se admiten actualmente para realizar migraciones del modelo clásico al de
Resource Manager. Si desea migrar una red virtual clásica con una instancia de Application Gateway, quite la puerta de
enlace antes de ejecutar una operación de preparación para mover la red. Después, cuando termine el proceso de
migración, vuelva a conectar la puerta de enlace en Azure Resource Manager.
Las puertas de enlace de ExpressRoute que se conectan con circuitos de ExpressRoute en otra suscripción no se pueden
migrar automáticamente. En esos casos, quite la puerta de enlace de ExpressRoute, migre la red virtual y vuelva a crear la
puerta de enlace. Para obtener más información, consulte Migración de circuitos de ExpressRoute y las redes virtuales
asociadas del modelo de implementación clásica a Resource Manager.
Paso 2: Instalar la versión más reciente de Azure PowerShell

Hay dos opciones principales para instalar Azure PowerShell: Galería de PowerShell o Instalador de plataforma
web (WebPI). WebPI recibe actualizaciones mensuales. La galería de PowerShell recibe actualizaciones de forma
continua. Este artículo se basa en los cmdlets de la versión 2.1.0 de Azure PowerShell.
Para ver las instrucciones de instalación, consulte Cómo instalar y configurar Azure PowerShell.
Paso 3: Asegurarse de que es administrador de la suscripción en

Azure Portal
Para realizar esta migración, debe estar agregado como coadministrador de la suscripción en Azure Portal.
1. Inicie sesión en el Portal de Azure.
2. En el menú de concentrador, seleccione Suscripción. Si no lo ve, haga clic en Todos los servicios.
3. Busque la entrada de la suscripción adecuada y después examine el campo MI ROL. Para un coadministrador,
el valor debe ser Administrador de cuenta.
Si no puede agregar un coadministrador, póngase en contacto con un administrador del servicio o
coadministrador de la suscripción para que le agreguen.
Paso 4: Establecer la suscripción y el registro para la migración

En primer lugar, inicie un símbolo del sistema de PowerShell. Para la migración, debe configurar el entorno para
el modelo clásico y el de Resource Manager.
Inicie sesión en su cuenta para el modelo de Resource Manager.
Connect-AzAccount
Puede encontrar las suscripciones disponibles ejecutando el siguiente comando:
Get-AzSubscription | Sort Name | Select Name
Establezca la suscripción de Azure para la sesión actual. En este ejemplo se establece el nombre de la suscripción
predeterminado en My Azure Subscription (Mi suscripción de Azure). Reemplace el nombre de la suscripción
de ejemplo por el suyo propio.
Select-AzSubscription –SubscriptionName "My Azure Subscription"
NOTE
El registro es un paso que solo se realiza una vez, pero debe hacerlo antes de intentar la migración. Si no se registra,
recibirá el siguiente mensaje de error:
BadRequest: La suscripción no está registrada para la migración.
Regístrese con el proveedor de recursos de migración ejecutando el comando siguiente:
Register-AzResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate
Espere cinco minutos a que finalice el registro. Puede comprobar el estado de la aprobación con el siguiente
comando:
Get-AzResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate
Asegúrese de que RegistrationState sea Registered antes de continuar.

Ahora inicie sesión en su cuenta para el modelo clásico.
Add-AzureAccount
Puede encontrar las suscripciones disponibles ejecutando el siguiente comando:
Get-AzureSubscription | Sort SubscriptionName | Select SubscriptionName
Establezca la suscripción de Azure para la sesión actual. En este ejemplo se establece la suscripción
predeterminada en My Azure Subscription (Mi suscripción de Azure). Reemplace el nombre de la suscripción
de ejemplo por el suyo propio.
Select-AzureSubscription –SubscriptionName "My Azure Subscription"
Paso 5: Asegurarse de tener suficientes unidades vCPU de máquina

virtual de Azure Resource Manager en la región de Azure de su VNET
o implementación actual
Puede usar el siguiente comando de PowerShell para comprobar la cantidad de vCPU que tiene actualmente en
Azure Resource Manager. Para obtener más información sobre las cuotas de vCPU, vea Límites y Azure
Resource Manager.
En este ejemplo se comprueba la disponibilidad en la región del oeste de EE. UU. Reemplace el nombre de la
región de ejemplo por el suyo propio.
Get-AzVMUsage -Location "West US"
Paso 6: Ejecutar comandos para migrar los recursos de IaaS

Migración de máquinas virtuales en un servicio en la nube (no en una red virtual)
Migración de máquinas virtuales en una red virtual
Migración de cuenta de almacenamiento
NOTE
Todas las operaciones que se describen aquí son idempotentes. Si tiene un problema diferente de una función no admitida
o un error de configuración, se recomienda que vuelva a intentar la operación de preparación, anulación o confirmación. La
plataforma intenta nuevamente la acción.
Paso 6.1: Opción 1: Migrar máquinas virtuales en un servicio en la nube (no en una red virtual)
Obtenga la lista de servicios en la nube mediante el siguiente comando y seleccione luego el servicio en la nube
que quiera migrar. Si las máquinas virtuales del servicio en la nube están en una red virtual o si tienen roles web
o de trabajo, el comando devolverá un mensaje de error.
Get-AzureService | ft Servicename
Obtenga el nombre de la implementación del servicio en la nube. En este ejemplo, el nombre de servicio es My
Service (Mi servicio). Reemplace el nombre del servicio de ejemplo por el suyo propio.
$serviceName = "My Service"

$deployment = Get-AzureDeployment -ServiceName $serviceName
$deploymentName = $deployment.DeploymentName
Prepare las máquinas virtuales del servicio en la nube para la migración. Tiene dos opciones para elegir.
Opción 1. Migrar las máquinas virtuales a una red virtual creada en una plataforma
Primero, valide si puede migrar el servicio en la nube con los siguientes comandos:
$validate = Move-AzureService -Validate -ServiceName $serviceName `

-DeploymentName $deploymentName -CreateNewVirtualNetwork
$validate.ValidationMessages
El comando siguiente muestra cualquier advertencia y error que bloquee la migración. Si la validación se
realiza correctamente, podrá pasar al siguiente paso de preparación:
Move-AzureService -Prepare -ServiceName $serviceName `

-DeploymentName $deploymentName -CreateNewVirtualNetwork
Opción 2. Migrar a una red virtual existente en el modelo de implementación de Resource

Manager
En este ejemplo se establece el nombre del grupo de recursos en myResourceGroup, el nombre de red
virtual en myVirtualNetwork y el nombre de la subred en mySubNet. Reemplace los nombres del
ejemplo por los nombres de sus propios recursos.
$existingVnetRGName = "myResourceGroup"
$vnetName = "myVirtualNetwork"
$subnetName = "mySubNet"
En primer lugar, valide si puede migrar la red virtual con el siguiente comando:
$validate = Move-AzureService -Validate -ServiceName $serviceName `

-DeploymentName $deploymentName -UseExistingVirtualNetwork -VirtualNetworkResourceGroupName
$existingVnetRGName -VirtualNetworkName $vnetName -SubnetName $subnetName
$validate.ValidationMessages
El comando siguiente muestra cualquier advertencia y error que bloquee la migración. Si la validación se
realiza correctamente, podrá continuar al siguiente paso de preparación:
Move-AzureService -Prepare -ServiceName $serviceName -DeploymentName $deploymentName `

-UseExistingVirtualNetwork -VirtualNetworkResourceGroupName $existingVnetRGName `
-VirtualNetworkName $vnetName -SubnetName $subnetName
Cuando la operación de preparación finalice correctamente con cualquiera de las opciones anteriores, consulte el
estado de la migración de las máquinas virtuales. Asegúrese de que tienen el estado Prepared .
En este ejemplo se establece el nombre de la máquina virtual en myVM. Reemplace el nombre del ejemplo por
su propio nombre de la máquina virtual.
$vmName = "myVM"
$vm = Get-AzureVM -ServiceName $serviceName -Name $vmName
$vm.VM.MigrationState
Compruebe la configuración de los recursos preparados mediante PowerShell o el Portal de Azure. Si no está
preparado para la migración y desea volver al estado anterior, utilice el siguiente comando:
Move-AzureService -Abort -ServiceName $serviceName -DeploymentName $deploymentName
Si la configuración preparada parece correcta, puede continuar y confirmar los recursos mediante el siguiente
comando:
Move-AzureService -Commit -ServiceName $serviceName -DeploymentName $deploymentName
Paso 6.1: Opción 2: Migrar máquinas virtuales en una red virtual

Para migrar máquinas virtuales de una red virtual, migre la red virtual. Las máquinas virtuales se migran
automáticamente con la red virtual. Seleccione la red virtual que quiere migrar.
NOTE
Migre una sola máquina virtual clásica creando una nueva máquina virtual de Resource Manager con discos administrados
mediante los archivos de VHD (SO y datos) de la máquina virtual.
NOTE
El nombre de red virtual podría ser diferente del que se muestra en el nuevo Portal. El nuevo Azure Portal muestra el
nombre como [vnet-name] pero el nombre de red virtual real es de tipo Group [resource-group-name] [vnet-name] .
Antes de migrar, busque el nombre real de la red virtual con el comando Get-AzureVnetSite | Select -Property Name
o consúltelo en el antiguo Azure Portal.
En este ejemplo se establece el nombre de red virtual en myVnet. Reemplace el nombre de la red virtual de
ejemplo por el suyo propio.
$vnetName = "myVnet"
NOTE
Si la red virtual contiene roles web o de trabajo, o bien máquinas virtuales con configuraciones no admitidas, recibe un
mensaje de error de validación.
En primer lugar, valide si puede migrar la red virtual con el siguiente comando:
Move-AzureVirtualNetwork -Validate -VirtualNetworkName $vnetName
El comando siguiente muestra cualquier advertencia y error que bloquee la migración. Si la validación se realiza
correctamente, podrá continuar al siguiente paso de preparación:
Move-AzureVirtualNetwork -Prepare -VirtualNetworkName $vnetName
Compruebe la configuración de las máquinas virtuales preparadas mediante Azure PowerShell o Azure Portal. Si
no está preparado para la migración y desea volver al estado anterior, utilice el siguiente comando:
Move-AzureVirtualNetwork -Abort -VirtualNetworkName $vnetName
Si la configuración preparada parece correcta, puede continuar y confirmar los recursos mediante el siguiente
comando:
Move-AzureVirtualNetwork -Commit -VirtualNetworkName $vnetName
Paso 6.2: Migración de una cuenta de almacenamiento

Cuando haya terminado de migrar las máquinas virtuales, se recomienda realizar las siguientes comprobaciones
de requisitos previos antes de migrar las cuentas de almacenamiento.
NOTE
Si su cuenta de almacenamiento no tenía discos asociados ni datos de máquina virtual, puede ir directamente a la sección
Validación de la cuenta de almacenamiento y comienzo de la migración.
Comprobación de requisitos previos si ha migrado cualquier máquina virtual o la cuenta de

almacenamiento tiene recursos de disco
Migración de máquinas virtuales clásicas cuyos discos se almacenan en la cuenta de
almacenamiento
El comando siguiente devuelve las propiedades RoleName y DiskName de todos los discos de
máquinas virtuales clásicas en la cuenta de almacenamiento. RoleName es el nombre de la
máquina virtual a la que está conectado el disco. Si este comando devuelve discos, asegúrese de
que las máquinas virtuales a las que están conectados estos discos se migraron antes de migrar la
cuenta de almacenamiento.
$storageAccountName = 'yourStorageAccountName'
Get-AzureDisk | where-Object {$_.MediaLink.Host.Contains($storageAccountName)} | Select-
Object -ExpandProperty AttachedTo -Property `
DiskName | Format-List -Property RoleName, DiskName
Eliminación de discos de máquinas virtuales clásicas almacenados en la cuenta de

almacenamiento
Busque discos de máquinas virtual es clásicas en la cuenta de almacenamiento con el comando
siguiente:
$storageAccountName = 'yourStorageAccountName'
Get-AzureDisk | where-Object {$_.MediaLink.Host.Contains($storageAccountName)} | Where-
Object -Property AttachedTo -EQ $null | Format-List -Property DiskName
Si el comando anterior devuelve discos, elimínelos con el comando siguiente:
Remove-AzureDisk -DiskName 'yourDiskName'
Eliminación de imágenes de máquinas virtuales almacenadas en la cuenta de

almacenamiento
El comando siguiente devuelve todas las imágenes de máquinas virtuales con el disco de SO
almacenado en la cuenta de almacenamiento.
Get-AzureVmImage | Where-Object { $_.OSDiskConfiguration.MediaLink -ne $null -and

$_.OSDiskConfiguration.MediaLink.Host.Contains($storageAccountName)`
} | Select-Object -Property ImageName, ImageLabel
El comando siguiente devuelve todas las imágenes de máquinas virtuales con discos de datos
almacenados en la cuenta de almacenamiento.
Get-AzureVmImage | Where-Object {$_.DataDiskConfigurations -ne $null `

-and ($_.DataDiskConfigurations | Where-Object
{$_.MediaLink -ne $null -and $_.MediaLink.Host.Contains($storageAccountName)}).Count -gt 0 `
} | Select-Object -Property ImageName, ImageLabel
Elimine todas las imágenes de máquinas virtuales que se devolvieron usando este comando:
Remove-AzureVMImage -ImageName 'yourImageName'
Validación de la cuenta de almacenamiento y comienzo de la migración

Valide cada cuenta de almacenamiento para la migración mediante el siguiente comando. En este ejemplo,
el nombre de cuenta de almacenamiento es myStorageAccount. Reemplace el nombre de ejemplo por el
nombre de su propia cuenta de almacenamiento.
$storageAccountName = "myStorageAccount"
Move-AzureStorageAccount -Validate -StorageAccountName $storageAccountName
El paso siguiente consiste en preparar la cuenta de almacenamiento para la migración
$storageAccountName = "myStorageAccount"
Move-AzureStorageAccount -Prepare -StorageAccountName $storageAccountName
Compruebe la configuración de la cuenta de almacenamiento preparada mediante Azure PowerShell o

Azure Portal. Si no está preparado para la migración y desea volver al estado anterior, utilice el siguiente
comando:
Move-AzureStorageAccount -Abort -StorageAccountName $storageAccountName
Si la configuración preparada parece correcta, puede continuar y confirmar los recursos mediante el
siguiente comando:
Move-AzureStorageAccount -Commit -StorageAccountName $storageAccountName
Pasos siguientes
Errores comunes durante la migración del modelo
clásico a Azure Resource Manager
En este artículo se catalogan los errores y las soluciones más comunes durante la migración de recursos de IaaS
del modelo de implementación clásica a la pila de Azure Resource Manager.
NOTE
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module
(Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az,
consulte Instalación de Azure PowerShell.
Lista de errores
CADENA DE ERROR MITIGACIÓN
Error interno del servidor En algunos casos, se trata de un error transitorio que
desaparece con un reintento. Si continúa, póngase en
contacto con el soporte técnico de Azure ya que será
necesario investigar los registros de la plataforma.
NOTA: Cuando la incidencia ya esté en manos del equipo de

soporte técnico, no intente ninguna mitigación de riesgos por
su cuenta ya que podría tener consecuencias imprevistas
sobre su entorno.
No se admite la migración para la implementación {nombre Esto sucede cuando una implementación contiene un rol web
de implementación} en HostedService {nombre del servicio o de trabajo. Dado que solo se admite la migración de
hospedado} porque es una implementación PaaS máquinas virtuales, quite el rol web o de trabajo de la
(web/trabajo). implementación y vuelva a intentar la migración.
Error de implementación de plantilla {nombre de plantilla}. En el back-end del servicio de migración, usamos plantillas de
CorrelationId={guid} Azure Resource Manager para crear recursos en la pila de
Azure Resource Manager. Puesto que las plantillas son
idempotentes, lo normal es que pueda reintentar la operación
de migración para solucionar este error. Si este error continúa,
póngase en contacto con el soporte técnico de Azure y
proporcióneles el CorrelationId.
NOTA: Cuando la incidencia ya esté en manos del equipo de

soporte técnico, no intente ninguna mitigación de riesgos por
su cuenta ya que podría tener consecuencias imprevistas
sobre su entorno.
La red virtual {nombre de la red virtual} no existe. Esto puede ocurrir si ha creado la red virtual en el nuevo
Azure Portal. El nombre de la red virtual real sigue el patrón
"Grupo * <nombre de VNET>"
La máquina virtual {nombre de la máquina virtual} de Las extensiones XML como BGInfo 1.* no se admiten en
HostedService {nombre del servicio hospedado} contiene la Azure Resource Manager. Por lo tanto, no se pueden migrar
extensión {nombre de la extensión} que no se admite en estas extensiones. Si estas extensiones se dejan instaladas en
Azure Resource Manager. Se recomienda desinstalarla de la la máquina virtual, se desinstalan automáticamente antes de
máquina virtual antes de continuar con la migración. completar la migración.
La máquina virtual {nombre de la máquina virtual} de Este es el escenario donde la máquina virtual está
HostedService {nombre del servicio hospedado} contiene la configurada para Azure Backup. Puesto que este no es
extensión VMSnapshot/VMSnapshotLinux que actualmente actualmente un escenario admitido, siga la solución
no se admite para migración. Desinstálela de la máquina alternativa en https://aka.ms/vmbackupmigration.
virtual y vuelva a agregarla mediante Azure Resource
Manager después de completar la migración
La máquina virtual {nombre de la máquina virtual} en Las extensiones del agente invitado de Azure y de la máquina
HostedService {nombre del servicio hospedado} contiene la virtual necesitan acceso de salida a Internet a la cuenta de
extensión {nombre de la extensión} cuyo estado no está almacenamiento de la máquina virtual para rellenar su
notificando la máquina virtual. Por lo tanto, esta máquina estado. Entre las causas comunes del error de estado se
virtual no se puede migrar. Asegúrese de que se notifica el incluyen:
estado de la extensión o desinstale la extensión de la Un grupo de seguridad de red que bloquea el acceso de
máquina virtual y vuelva a intentar la migración. salida a Internet.
Si la red virtual tiene servidores DNS locales y se pierde la
La máquina virtual {nombre de la máquina virtual} en conectividad con DNS
HostedService {nombre del servicio hospedado} contiene la
extensión {nombre de la extensión} que notifica el estado del Si continúa viendo un estado no admitido, puede desinstalar
controlador: {estado del controlador}. Por lo tanto, la VM no las extensiones para omitir esta comprobación y seguir
se puede migra. Asegúrese de que el estado del controlador adelante con la migración.
de la extensión que se notifica sea {estado del controlador} o
desinstálelo de la máquina virtual y vuelva a intentar la
migración.
El agente de máquina virtual de la máquina virtual {nombre

de la máquina virtual} en HostedService {nombre del servicio
hospedado} está notificando el estado general del agente
como no preparado. Por lo tanto si tiene una extensión que
es migrable, la máquina virtual no se puede migrar.
Asegúrese de que el agente de máquina virtual está
notificando el estado general del agente como listo. Consulte
https://aka.ms/classiciaasmigrationfaqs.
No se admite la migración para la implementación {nombre Actualmente, solo se pueden migrar los servicios hospedados
de implementación} en HostedService {nombre del servicio que tengan como mucho un conjunto de disponibilidad. Para
hospedado} porque tiene varios conjuntos de disponibilidad. solucionar este problema, mueva los conjuntos de
disponibilidad adicionales y las máquinas virtuales de esos
conjuntos de disponibilidad a otro servicio hospedado.
No se admite la migración para la implementación {nombre En este escenario la solución consiste en mover todas las
de implementación} en HostedService {nombre del servicio máquinas virtuales a un único conjunto de disponibilidad o
hospedado} porque tiene máquinas virtuales que no forman quitar todas las máquinas virtuales del conjunto de
parte del conjunto de disponibilidad aunque HostedService disponibilidad en el servicio hospedado.
contiene uno.
La cuenta de almacenamiento/HostedService/red virtual Este error se produce cuando la operación para preparar la
{nombre de la red virtual} está en proceso de ser migrada y migración se ha completado en el recurso y se desencadena
por tanto no se puede cambiar. una operación que haría un cambio en él. Debido al bloqueo
en el plano de administración después de la operación de
preparación, todos los cambios en el recurso se bloquean.
Para desbloquear el plano de administración, puede ejecutar
la operación de confirmación de la migración para completar
la migración o la operación de anulación de la migración para
revertir a la operación de preparación.
No se permite la migración para HostedService {nombre del La máquina virtual podría estar experimentando una
servicio hospedado} porque tiene una máquina virtual transición de estado que normalmente sucede durante una
{nombre de la máquina virtual} en estado: operación de actualización en HostedService, como un
RoleStateUnknown. La migración solo se permite cuando la reinicio, la instalación de una extensión, etc. Se recomienda
máquina virtual tiene uno de los siguientes estados: En completar la operación de actualización en HostedService
ejecución, Detenido, Detenido (desasignado). antes de intentar la migración.
La implementación {nombre-implementación} en Este error se produce si ha cambiado el tamaño del blob de

HostedService {nombre-servicio-hospedado} contiene una disco duro virtual sin actualizar el tamaño en el modelo de la
máquina virtual {nombre-máquina-virtual} con el disco de API de la máquina virtual. A continuación, se describen los
datos {nombre-disco-datos} cuyos bytes de tamaño de blob pasos de mitigación detallados.
físico {tamaño-blob-vhd-que-realiza-copia-seguridad-disco-
datos} no coinciden con los del tamaño lógico del disco de
datos de la máquina virtual {tamaño-disco-datos-
especificado-en-api-máquina-virtual}. La migración
continuará sin especificar un tamaño para el disco de datos
de la máquina virtual de Azure Resource Manager.
Se produjo una excepción de almacenamiento durante la Este error puede ocurrir si los discos de la máquina virtual se
validación de datos de un disco {nombre de disco de datos} han eliminado o ya no son accesibles. Asegúrese de que
con el vínculo multimedia {URI de disco de datos} para la existan los discos de la máquina virtual.
máquina virtual {nombre de máquina virtual} en el servicio en
la nube {nombre del servicio en la nube}. Asegúrese de que
esta máquina virtual puede acceder al vínculo de medios del
VHD
La máquina virtual {vm-name} de HostedService {cloud- Este error se produce cuando el nombre del blob tiene un "/"
service-name} contiene un disco con MediaLink {vhd-uri} que que no admite actualmente el proveedor de recursos del
tiene un nombre de blob {vhd-blob-name} que no se admite proceso.
en Azure Resource Manager.
No se permite la migración de la implementación En 2014, Azure anunció que los recursos de red se moverían
{deployment-name} en HostedService {cloud-service-name} de un ámbito de nivel de clúster a un ámbito regional. Para
porque no se encuentra en el ámbito regional. Vea obtener más información, vea https://aka.ms/regionalscope.
https://aka.ms/regionalscope para mover esta Este error se produce cuando en la implementación que se va
implementación a un ámbito regional. a migrar no se ha realizado ninguna operación de
actualización que la mueva automáticamente a un ámbito
regional. La mejor solución alternativa consiste en agregar un
punto de conexión a una máquina virtual o un disco de datos
a la máquina virtual y, después, volver a intentar la migración.
Vea Configuración de puntos de conexión en una máquina
virtual de Windows clásica en Azure o Conecte un disco de
datos a una máquina virtual de Windows creada con el
La migración no se admite para la red virtual {vnet-name} Este error se produce cuando tiene implementaciones PaaS
porque tiene implementaciones PaaS que no son de puerta que no son de puerta de enlace como, por ejemplo, los
de enlace. servicios Application Gateway o API Management que están
conectados a la red virtual.
Mitigaciones detalladas
Máquina virtual con disco de datos cuyos bytes de tamaño de blob físico no coinciden con los del tamaño
lógico del disco de datos de la máquina virtual.
Esto se produce cuando el tamaño lógico del disco de datos pueda desincronizarse con el tamaño real del blob de
disco duro virtual. Esto se puede comprobar fácilmente utilizando los comandos siguientes:
Comprobación del problema
# Store the VM details in the VM object

$vm = Get-AzureVM -ServiceName $servicename -Name $vmname
# Display the data disk properties

# NOTE the data disk LogicalDiskSizeInGB below which is 11GB. Also note the MediaLink Uri of the VHD blob as
we'll use this in the next step
$vm.VM.DataVirtualHardDisks
HostCaching : None
DiskLabel :
DiskName : coreosvm-coreosvm-0-201611230636240687
Lun : 0
LogicalDiskSizeInGB : 11
MediaLink : https://contosostorage.blob.core.windows.net/vhds/coreosvm-dd1.vhd
SourceMediaLink :
IOType : Standard
ExtensionData :
# Now get the properties of the blob backing the data disk above
# NOTE the size of the blob is about 15 GB which is different from LogicalDiskSizeInGB above
$blob = Get-AzStorageblob -Blob "coreosvm-dd1.vhd" -Container vhds
$blob
ICloudBlob : Microsoft.WindowsAzure.Storage.Blob.CloudPageBlob
BlobType : PageBlob
Length : 16106127872
ContentType : application/octet-stream
LastModified : 11/23/2016 7:16:22 AM +00:00
SnapshotTime :
ContinuationToken :
Context : Microsoft.WindowsAzure.Commands.Common.Storage.AzureStorageContext
Name : coreosvm-dd1.vhd
Mitigación del problema
# Convert the blob size in bytes to GB into a variable which we'll use later
$newSize = [int]($blob.Length / 1GB)
# See the calculated size in GB

$newSize
15
# Store the disk name of the data disk as we'll use this to identify the disk to be updated
$diskName = $vm.VM.DataVirtualHardDisks[0].DiskName
# Identify the LUN of the data disk to remove

$lunToRemove = $vm.VM.DataVirtualHardDisks[0].Lun
# Now remove the data disk from the VM so that the disk isn't leased by the VM and it's size can be updated
Remove-AzureDataDisk -LUN $lunToRemove -VM $vm | Update-AzureVm -Name $vmname -ServiceName $servicename
OperationDescription OperationId OperationStatus

-------------------- ----------- ---------------
Update-AzureVM 213xx1-b44b-1v6n-23gg-591f2a13cd16 Succeeded
Update-AzureVM 213xx1-b44b-1v6n-23gg-591f2a13cd16 Succeeded
# Verify we have the right disk that's going to be updated

Get-AzureDisk -DiskName $diskName
AffinityGroup :
AttachedTo :
IsCorrupted : False
Label :
Location : East US
DiskSizeInGB : 11
SourceImageName :
OS :
IOType : Standard
OperationDescription : Get-AzureDisk
OperationId : 0c56a2b7-a325-123b-7043-74c27d5a61fd
OperationStatus : Succeeded
# Now update the disk to the new size

Update-AzureDisk -DiskName $diskName -ResizedSizeInGB $newSize -Label $diskName

-------------------- ----------- ---------------
Update-AzureDisk cv134b65-1b6n-8908-abuo-ce9e395ac3e7 Succeeded
# Now verify that the "DiskSizeInGB" property of the disk matches the size of the blob
Get-AzureDisk -DiskName $diskName
AffinityGroup :
AttachedTo :
IsCorrupted : False
Label : coreosvm-coreosvm-0-201611230636240687
Location : East US
DiskSizeInGB : 15
SourceImageName :
OS :
IOType : Standard
OperationDescription : Get-AzureDisk
OperationId : 1v53bde5-cv56-5621-9078-16b9c8a0bad2
OperationStatus : Succeeded
# Now we'll add the disk back to the VM as a data disk. First we need to get an updated VM object
$vm = Get-AzureVM -ServiceName $servicename -Name $vmname
Add-AzureDataDisk -Import -DiskName $diskName -LUN 0 -VM $vm -HostCaching ReadWrite | Update-AzureVm -Name
$vmname -ServiceName $servicename

-------------------- ----------- ---------------
Update-AzureVM b0ad3d4c-4v68-45vb-xxc1-134fd010d0f8 Succeeded
Movimiento de una máquina virtual a una suscripción diferente tras completar una migración
Después de completar el proceso de migración, puede que desee mover la máquina virtual a otra suscripción. Sin
embargo, si tiene un certificado de clave en la máquina virtual que hace referencia a un recurso de Key Vault, el
movimiento actualmente no se admite. Estas instrucciones le permiten solucionar el problema.
PowerShell
$vm = Get-AzVM -ResourceGroupName "MyRG" -Name "MyVM"
Remove-AzVMSecret -VM $vm
Update-AzVM -ResourceGroupName "MyRG" -VM $vm
CLI de Azure
az vm update -g "myrg" -n "myvm" --set osProfile.Secrets=[]
Pasos siguientes
Revisión de las preguntas más frecuentes acerca de cómo migrar recursos de IaaS del modelo de
Herramientas de la comunidad para la migración de
recursos de IaaS de la implementación clásica a
En este artículo se catalogan las herramientas que la comunidad proporcionó para ayudar en la migración de los
recursos de IaaS del modelo de implementación clásico al de Azure Resource Manager.
NOTE
Estas herramientas no se incluyen en el soporte técnico de Microsoft. Por lo tanto, son de código abierto en GitHub y
estamos encantados de aceptar PR para correcciones o escenarios adicionales. Para informar sobre un problema, use la
característica de problemas de GitHub.
La migración con estas herramientas provocará tiempo de inactividad en la máquina virtual clásica. Si lo que busca es
información sobre la migración compatible con la plataforma, visite
Migración compatible con la plataforma de recursos de IaaS del modelo clásico al de Azure Resource Manager
Technical Deep Dive on Platform supported migration from Classic to Azure Resource Manager (Profundización técnica
en la migración compatible con la plataforma de la implementación clásica a la de Azure Resource Manager)
AsmMetadataParser
Se trata de una colección de herramientas auxiliares creadas como parte de las migraciones empresariales de
Azure Service Management a Azure Resource Manager. Esta herramienta permite replicar la infraestructura en
otra suscripción, que puede usarse para probar la migración y resolver los posibles problemas antes de ejecutar
la migración en la suscripción de producción.
Vínculo a la documentación sobre la herramienta
migAz
migAz es una opción adicional para migrar un conjunto completo de recursos de IaaS clásicos a recursos de IaaS
de Azure Resource Manager. La migración se puede producir dentro de la misma suscripción o entre
suscripciones y tipos de suscripción distintos (por ejemplo, suscripciones de CSP ).
Vínculo a la documentación sobre la herramienta
Pasos siguientes
Preguntas más frecuentes sobre la migración del
método clásico al de Azure Resource Manager
¿Afecta este plan de migración a alguno de los servicios o las

aplicaciones existentes que se ejecutan en máquinas virtuales de
Azure?
No. Las máquinas virtuales (clásicas) son servicios totalmente compatibles en la disponibilidad general. Puede
seguir usando estos recursos para expandir su huella en Microsoft Azure.
¿Qué ocurre con mis máquinas virtuales si por ahora no tengo

planeado migrar?
Las API y el modelo de recursos clásicos existentes no van a quedar en desuso. Queremos facilitar la migración,
dadas las características avanzadas disponibles en el modelo de implementación de Resource Manager. Es muy
recomendable que repase algunos de los avances realizados como parte de IaaS en Resource Manager.
¿Qué supone este plan de migración para las herramientas existentes?

La actualización de sus herramientas al modelo de implementación de Resource Manager es uno de los cambios
más importantes que tendrá que considerar en sus planes de migración.
¿Cuánto tiempo durará el tiempo de inactividad del plano de

administración?
Depende del número de recursos que se vayan a migrar. Para las implementaciones más pequeñas (unas decenas
de máquinas virtuales), el proceso completo de migración debería tardar menos de una hora. Para
implementaciones a gran escala (cientos de máquinas virtuales), la migración puede tardar unas horas.
¿Puedo revertir el proceso después de que la migración de los

recursos esté confirmada en Resource Manager?
Puede anular la migración siempre que los recursos se encuentren en el estado preparado. No se puede revertir
una vez que los recursos se hayan migrado correctamente mediante la operación de confirmación.
¿Puedo revertir la migración si se produce un error en la operación de

confirmación?
No se puede anular la migración si se produce un error en la operación de confirmación. Todas las operaciones
de migración, incluida la de confirmación, son idempotentes. Por consiguiente, se recomienda que vuelva a
intentar la operación en breve. Si sigue apareciendo un error, cree una incidencia de soporte técnico o publique
una entrada con la etiqueta ClassicIaaSMigration en el foro de máquinas virtuales.
¿Tengo que comprar otro circuito de ExpressRoute para usar IaaS en

Resource Manager?
No. Hace poco hemos habilitado la transición de los circuitos ExpressRoute del modelo de implementación
clásica al modelo de implementación de Resource Manager. No hace falta que compre un nuevo circuito de
ExpressRoute si ya tiene uno.
¿Qué ocurre si había configurado las directivas de control de acceso

basado en rol para mis recursos IaaS clásicos?
Durante la migración, los recursos se transforman del modelo clásico al de Resource Manager. Por lo tanto, se
recomienda que planee las actualizaciones de directiva de RBAC que deben producirse después de la migración.
He realizado copias de seguridad de mis máquinas virtuales clásicas en

un almacén. ¿Puedo migrar mis máquinas virtuales del modo clásico al
modo de Resource Manager y protegerlos en un almacén de Recovery
Services?
traslade una máquina virtual del modo clásico al de Resource Manager, las copias de seguridad realizadas antes
Cuando
de la migración no migrarán a la máquina virtual de Resource Manager recién migrada. Sin embargo, si quiere
mantener las copias de seguridad de las máquinas virtuales clásicas, siga estos pasos antes de la migración.
1. En el almacén de Recovery Services, vaya a la pestaña Elementos protegidos y seleccione la máquina
virtual.
2. Haga clic en Stop Protection (Detener protección). Deje la opción Eliminar los datos de copia de seguridad
asociados desactivada.
NOTE
Se le cobrará el costo de la instancia de la copia de seguridad hasta que retenga los datos. Las copias de seguridad se
eliminarán según el intervalo de retención. Sin embargo, siempre se conserva la última copia de seguridad hasta que
elimina explícitamente los datos de copia de seguridad. Se recomienda comprobar el intervalo de retención de la máquina
virtual y el desencadenador "Eliminar datos de copia de seguridad" en el elemento protegido en el almacén una vez
finalizado el intervalo de retención.
Para migrar la máquina virtual al modo de Resource Manager:

1. Elimine la extensión de instantánea o copia de seguridad de la máquina virtual.
2. Migre la máquina virtual del modo clásico al modo de Resource Manager. Asegúrese de que la información
de almacenamiento y red correspondiente a la máquina virtual también se migra al modo de Resource
Manager.
Además, si quiere hacer una copia de seguridad de la máquina virtual migrada, vaya a la hoja Administración de
máquina virtual para habilitar la copia de seguridad.
¿Puedo validar mi suscripción o mis recursos para ver si son aptos para
la migración?
Sí. En la opción de migración compatible con la plataforma, el primer paso para preparar la migración consiste en
validar si los recursos pueden migrarse. Si se produce un error en la operación de validación, recibe todos los
mensajes con todas las razones por las que no se puede completar la migración.
¿Qué ocurre si se produce un error de cuota mientras preparo los

recursos IaaS para la migración?
Se recomienda que anule la migración y, a continuación, presente una solicitud de soporte técnico para que se
aumenten las cuotas en la región donde vaya a migrar las máquinas virtuales. Una vez aprobada la solicitud de
cuotas, puede empezar a ejecutar los pasos de la migración.
¿Cómo se informa de un problema?

Publique sus problemas y preguntas sobre la migración en nuestro foro de máquinas virtualescon la palabra
clave ClassicIaaSMigration. Se recomienda registrar todas sus preguntas en este foro. Si tiene un contrato de
soporte técnico, también puede presentar una incidencia de soporte técnico.
¿Qué hago si no me gustan los nombres que eligió la plataforma para

los recursos durante la migración?
Todos los recursos para los que se proporcionen nombres explícitamente en el modelo de implementación clásica
se conservan durante la migración. En algunos casos, se crean recursos nuevos. Por ejemplo, se crea una interfaz
de red para cada máquina virtual. Actualmente, no se admite la capacidad de controlar los nombres de estos
recursos nuevos creados durante la migración. Registre sus votos para esta característica en el foro de
comentarios de Azure.
¿Puedo migrar circuitos de ExpressRoute utilizados en las

suscripciones con vínculos de autorización?
Los circuitos de ExpressRoute que usan vínculos de autorización entre suscripciones no se pueden migrar
automáticamente sin tiempo de inactividad. Contamos con instrucciones sobre cómo se pueden migrar mediante
pasos manuales. Para conocer los pasos que deben darse y obtener más información, consulte Migración de
circuitos ExpressRoute y las redes virtuales asociadas del modelo de implementación clásica a Resource
Manager.
Aparece el mensaje "La máquina virtual notifica el estado de agente

general No preparado. Por lo tanto, la VM no se puede migra.
Asegúrese de que el agente de VM notifica el estado de agente general
como Preparado" o "la máquina virtual contiene la extensión cuyo
estado no se notifica desde la VM. Por lo tanto, esta máquina virtual no
se puede migrar."
Este mensaje se recibe cuando la máquina virtual no tiene conectividad saliente a Internet. El agente de VM
utiliza conectividad saliente para llegar a la cuenta de almacenamiento de Azure a fin de actualizar el estado del
agente cada cinco minutos.
Pasos siguientes
Herramientas de solución de problemas
Consola serie
Diagnósticos de arranque
Máquina virtual Windows: Conexión del disco del sistema operativo con otra máquina virtual para solucionar problemas
Máquina virtual Linux: Conexión del disco del sistema operativo con otra máquina virtual para solucionar problemas
No puedo conectarme a la máquina virtual

Windows
Solución habitual
Restablecimiento de RDP
Solución de problemas de RDP
Solución de problemas detallada de RDP
Errores de RDP
No hay servidor de licencias
Un interno
errores de autenticación
Solución de errores específicos
Errores al arrancar la máquina virtual
Errores de arranque de BitLocker
Windows muestra "Comprobando el sistema de archivos" durante el arranque
Errores de pantalla azul
El inicio de la máquina virtual está detenido en "Preparando Windows
Pantalla azul con el mensaje "ERROR CRÍTICO DEL SERVICIO"
Problema de bucle de reinicio
El inicio de la máquina virtual está atascado en una fase de actualización de Windows
La máquina virtual arranca en modo seguro
Otros
Restablezca la contraseña de máquina virtual de la máquina virtual Windows sin conexión
Restablezca la NIC después de una configuración incompleta
Linux
Solución de problemas de SSH
Solución de problemas detallada de SSH
Mensajes comunes de error
Restablezca la contraseña de máquina virtual de la máquina virtual Linux sin conexión
Problemas de implementación de máquinas virtuales

Errores de asignación
Reimplementación de una máquina virtual
Linux
Windows
Solución de problemas de implementaciones
Linux
Windows
Se cambian los nombres de dispositivos
Instalación del agente de máquina virtual Windows sin conexión
Reinicio o cambio de tamaño de una máquina virtual
Problema de rendimiento de la máquina virtual

Problemas de rendimiento con máquinas virtuales
Windows
Uso de PerfInsights
Extensión de diagnóstico de rendimiento
Linux
Uso de PerfInsights
Nociones sobre la estructura y la sintaxis de las plantillas
de Azure Resource Manager
En este artículo se describe la estructura de una plantilla de Azure Resource Manager. Presenta las distintas secciones de
una plantilla y las propiedades que están disponibles en esas secciones.
Este artículo está destinado a los usuarios que ya estén familiarizados con las plantillas de Resource Manager. Proporciona
información detallada sobre la estructura de la plantilla. Para obtener un tutorial paso a paso que le guíe en el proceso de
creación de una plantilla, consulte Tutorial: Creación e implementación de la primera plantilla de Azure Resource Manager.
Formato de plantilla
En la estructura más simple, una plantilla tiene los siguientes elementos:
{
"contentVersion": "",
"apiProfile": "",
"parameters": { },
"variables": { },
"functions": [ ],
"resources": [ ],
"outputs": { }
}
NOMBRE DEL ELEMENTO OBLIGATORIO DESCRIPCIÓN
$schema Sí Ubicación del archivo de esquema JSON

que describe la versión del idioma de la
plantilla.
Para las implementaciones de grupos de

recursos, use:
https://schema.management.azure.com/schemas/2015-
01-01/deploymentTemplate.json#
.
Para las implementaciones de

suscripciones, use:
https://schema.management.azure.com/schemas/2018-
05-01/subscriptionDeploymentTemplate.json#
.
contentVersion Sí Versión de la plantilla (por ejemplo,

1.0.0.0). Puede especificar cualquier valor
para este elemento. Use este valor para
documentar los cambios importantes de la
plantilla. Al implementar los recursos con la
plantilla, este valor se puede usar para
asegurarse de que se está usando la
plantilla correcta.
apiProfile Sin Una versión de API que actúa como una

colección de versiones de API para los
tipos de recursos. Use este valor para
evitar tener que especificar las versiones de
API para cada recurso de la plantilla. Si
especifica una versión del perfil de API y no
especifica una versión de API para el tipo
de recurso, Resource Manager usa la
versión de API para el tipo de recurso que
está definido en el perfil.
La propiedad del perfil de API es

especialmente útil al implementar una
plantilla en diferentes entornos, como
Azure Stack y Azure global. Use la versión
del perfil de API para asegurarse de que la
plantilla utilice automáticamente las
versiones que se admiten en ambos
entornos. Para obtener una lista de las
versiones del perfil de API actuales y de las
versiones de API de recursos definidas en
el perfil, consulte API Profile (Perfil de API).
Para más información, consulte

Seguimiento de versiones mediante perfiles
de API.
parameters Sin Valores que se proporcionan cuando se

ejecuta la implementación para
personalizar la implementación de
recursos.
variables Sin Valores que se usan como fragmentos

JSON en la plantilla para simplificar
expresiones de idioma de la plantilla.
functions Sin Funciones definidas por el usuario que

están disponibles dentro de la plantilla.
resources Sí Tipos de servicios que se implementan o

actualizan en un grupo de recursos o
suscripción.
outputs Sin Valores que se devuelven después de la

implementación.
Cada elemento tiene propiedades que puede configurar. En este artículo se describen las secciones de la plantilla con más
detalle.
Parámetros
En la sección de parámetros de la plantilla, especifique los valores que el usuario puede introducir al implementar los
recursos. Está limitado a 256 parámetros en una plantilla. Puede reducir el número de parámetros mediante el uso de
objetos que contienen varias propiedades.
Las propiedades disponibles para un parámetro son:
"parameters": {
"<parameter-name>" : {
"type" : "<type-of-parameter-value>",
"defaultValue": "<default-value-of-parameter>",
"allowedValues": [ "<array-of-allowed-values>" ],
"minValue": <minimum-value-for-int>,
"maxValue": <maximum-value-for-int>,
"minLength": <minimum-length-for-string-or-array>,
"maxLength": <maximum-length-for-string-or-array-parameters>,
"metadata": {
"description": "<description-of-the parameter>"
}
}
}
nombre-del-parámetro Sí Nombre del parámetro. Debe ser un

identificador válido de JavaScript.
type Sí Tipo del valor del parámetro. Los tipos y

valores permitidos son string,
secureString, int, bool, objet,
secureObject y array. Consulte Tipos de
datos.
defaultValue Sin Valor predeterminado del parámetro, si no

se proporciona ningún valor.
allowedValues Sin Matriz de valores permitidos para el

parámetro para asegurarse de que se
proporciona el valor correcto.
minValue Sin El valor mínimo de parámetros de tipo int,

este valor es inclusivo.
maxValue Sin El valor máximo de parámetros de tipo int,

este valor es inclusivo.
minLength Sin Longitud mínima de los parámetros de

tipo cadena, cadena segura y matriz; este
valor es inclusivo.
maxLength Sin Longitud máxima de los parámetros de

tipo cadena, cadena segura y matriz; este
valor es inclusivo.
description Sin Descripción del parámetro que se muestra

a los usuarios a través del portal. Para más
información, consulte Comentarios en
plantillas.
Para ejemplos de cómo usar los parámetros, consulte Parámetros en plantillas de Azure Resource Manager.
Tipos de datos
En el caso de los enteros pasados como parámetros en línea, el intervalo de valores puede estar limitado por el SDK o la
herramienta de línea de comandos que use para la implementación. Por ejemplo, al usar PowerShell para implementar una
plantilla, los tipos de enteros pueden oscilar entre -2 147 483 648 y 2 147 483 647. Para evitar esta limitación, especifique
valores enteros grandes en un archivo de parámetros. Los tipos de recursos aplican sus propios límites para las
propiedades de enteros.
Al especificar valores booleanos y enteros en la plantilla, no incluya el valor entre comillas. Los valores de cadena inicial y
final se incluyen entre comillas dobles.
Los objetos comienzan con una llave de apertura y terminan con una llave de cierre. Las matrices comienzan con un
corchete de apertura y terminan con un corchete de cierre.
Las cadenas seguras y los objetos seguros no se pueden leer después de la implementación de recursos.
Para obtener ejemplos de tipos de datos de formato, consulte Formatos de tipo de parámetro.
variables
En la sección de variables, se crean valores que pueden usarse en toda la plantilla. No es necesario definir las variables,
pero a menudo simplifican la plantilla reduciendo expresiones complejas.
En el ejemplo siguiente se muestran las opciones disponibles para definir una variable:
"variables": {
"<variable-name>": "<variable-value>",
"<variable-name>": {
<variable-complex-type-value>
},
"<variable-object-name>": {
"copy": [
{
"name": "<name-of-array-property>",
"count": <number-of-iterations>,
"input": <object-or-value-to-repeat>
}
]
},
"copy": [
{
"name": "<variable-array-name>",
"input": <object-or-value-to-repeat>
}
]
}
Si desea información sobre el uso de copy para crear varios valores para una variable, consulte Iteración de variables.
Para ejemplos de cómo usar las variables, consulte Variables en plantillas de Azure Resource Manager.
Functions
Dentro de la plantilla, puede crear sus propias funciones. Estas funciones están disponibles para su uso en la plantilla.
Normalmente, definirá expresiones complejas que no desea repetir en toda la plantilla. Creará las funciones definidas por
el usuario a partir de las expresiones y funciones que se admiten en las plantillas.
Al definir una función de usuario, hay algunas restricciones:
La función no puede acceder a las variables.
La función solo puede usar los parámetros que se definen en la función. Cuando usa la función parameters dentro de
una función definida por el usuario, los parámetros de esa función serán los que limiten sus acciones.
La función no puede llamar a otras funciones definidas por el usuario.
La función no puede usar la función de referencia.
Los parámetros de la función no pueden tener valores predeterminados.
"functions": [
{
"namespace": "<namespace-for-functions>",
"members": {
"<function-name>": {
"parameters": [
{
"name": "<parameter-name>",
"type": "<type-of-parameter-value>"
}
],
"output": {
"type": "<type-of-output-value>",
"value": "<function-return-value>"
}
}
}
}
],
espacio de nombres Sí Espacio de nombres para las funciones

personalizadas. Se usa para evitar
conflictos de nomenclatura con funciones
de plantilla.
nombre-de-la-función Sí Nombre de la función personalizada. Al

llamar a la función, combine el nombre de
la función con el espacio de nombres. Por
ejemplo, para llamar a una función
denominada uniqueName en el espacio de
nombres contoso, use
"[contoso.uniqueName()]" .
nombre-del-parámetro Sin Nombre del parámetro que se va a usar en

la función personalizada.
valor-del-parámetro Sin Tipo del valor del parámetro. Los tipos y

valores permitidos son string,
secureString, int, bool, objet,
secureObject y array.
tipo de salida Sí Tipo del valor de salida. Los valores de

salida admiten los mismos tipos que los
parámetros de entrada de función.
valor de salida Sí Expresión de lenguaje de plantilla que se

evalúa y devuelve desde la función.
Para ejemplos de cómo usar las funciones personalizadas, consulte Funciones definidas por el usuario de la plantilla de
Azure Resource Manager.
Recursos
En la sección de recursos, se define que los recursos se implementan o se actualizan.
Defina recursos con la siguiente estructura:
"resources": [
{
"condition": "<true-to-deploy-this-resource>",
"apiVersion": "<api-version-of-resource>",
"type": "<resource-provider-namespace/resource-type-name>",
"name": "<name-of-the-resource>",
"location": "<location-of-resource>",
"tags": {
"<tag-name1>": "<tag-value1>",
"<tag-name2>": "<tag-value2>"
},
"comments": "<your-reference-notes>",
"copy": {
"name": "<name-of-copy-loop>",
"mode": "<serial-or-parallel>",
"batchSize": <number-to-deploy-serially>
},
"dependsOn": [
"<array-of-related-resource-names>"
],
"properties": {
"<settings-for-the-resource>",
"copy": [
{
"name": ,
"count": ,
"input": {}
}
]
},
"sku": {
"name": "<sku-name>",
"tier": "<sku-tier>",
"size": "<sku-size>",
"family": "<sku-family>",
"capacity": <sku-capacity>
},
"kind": "<type-of-resource>",
"plan": {
"name": "<plan-name>",
"promotionCode": "<plan-promotion-code>",
"publisher": "<plan-publisher>",
"product": "<plan-product>",
"version": "<plan-version>"
},
"resources": [
"<array-of-child-resources>"
]
}
]
condition Sin Valor booleano que indica si el recurso se

aprovisionará durante esta
implementación. Si es true , el recurso se
crea durante la implementación. Si es
false , el recurso se omite para esta
implementación. Consulte condition.
apiVersion Sí Versión de la API de REST que debe usar

para crear el recurso. Para determinar los
valores disponibles, consulte la referencia
de plantilla.
type Sí Tipo de recurso. Este valor es una

combinación del espacio de nombres del
proveedor de recursos y el tipo de recurso
(como
Microsoft.Storage/storageAccounts).
Para determinar los valores disponibles,
consulte la referencia de plantilla. Para un
recurso secundario, el formato del tipo
depende de si está anidado dentro del
recurso primario o se ha definido fuera del
recurso primario. Consulte Establecimiento
del nombre y el tipo de recursos
secundarios.
Nombre Sí Nombre del recurso. El nombre debe

cumplir las restricciones de componente
URI definidas en RFC3986. Los servicios de
Azure que exponen el nombre del recurso
a partes externas validan el nombre para
asegurarse de que no es un intento de
suplantar otra identidad. Para un recurso
secundario, el formato del nombre
depende de si está anidado dentro del
recurso primario o se ha definido fuera del
recurso primario. Consulte Establecimiento
del nombre y el tipo de recursos
secundarios.
location Varía Ubicaciones geográficas compatibles del

recurso proporcionado. Puede seleccionar
cualquiera de las ubicaciones disponibles,
pero normalmente tiene sentido elegir
aquella que esté más cerca de los usuarios.
Normalmente, también tiene sentido
colocar los recursos que interactúan entre
sí en la misma región. La mayoría de los
tipos de recursos requieren una ubicación,
pero algunos (por ejemplo, una asignación
de roles) no la necesitan. Consulte
Establecimiento de la ubicación del recurso.
etiquetas Sin Etiquetas asociadas al recurso. Aplique

etiquetas para organizar de forma lógica
los recursos en su suscripción.
comentarios Sin Notas para documentar los recursos de la

plantilla. Para más información, consulte
Comentarios en plantillas.
copia Sin Si se necesita más de una instancia, el

número de recursos que se crearán. El
modo predeterminado es paralelo. Si no
desea que todos los recursos se
implementen al mismo tiempo, especifique
el modo serie. Para obtener más
información, consulte Creación de varias
instancias de recursos en Azure Resource
Manager.
dependsOn Sin Recursos que se deben implementar antes

de implementar este. Resource Manager
evalúa las dependencias entre recursos y
los implementa en su orden correcto.
Cuando no hay recursos dependientes
entre sí, se implementan en paralelo. El
valor puede ser una lista separada por
comas de nombres de recursos o
identificadores de recursos únicos. Solo los
recursos de lista que se implementan en
esta plantilla. Deben existir los recursos
que no estén definidos en esta plantilla.
Evite agregar dependencias innecesarias,
ya que pueden ralentizar la
implementación y crear dependencias
circulares. Para obtener instrucciones sobre
la configuración de dependencias, consulte
Definición de dependencias en plantillas de
Azure Resource Manager.
properties Sin Opciones de configuración específicas de

recursos. Los valores de las propiedades
son exactamente los mismos valores que
se especifican en el cuerpo de la solicitud
de la operación de API de REST (método
PUT) para crear el recurso. También puede
especificar una matriz de copia para crear
varias instancias de una propiedad. Para
determinar los valores disponibles,
consulte la referencia de plantilla.
sku Sin Algunos recursos permiten valores que

definen la SKU que se va a implementar.
Por ejemplo, puede especificar el tipo de
redundancia para una cuenta de
almacenamiento.
kind Sin Algunos recursos permiten un valor que

define el tipo de recurso que va a
implementar. Por ejemplo, puede
especificar el tipo de instancia de Cosmos
DB que va a crear.
plan Sin Algunos recursos permiten valores que

definen el plan que se va a implementar.
Por ejemplo, puede especificar la imagen
de Marketplace para una máquina virtual.
resources Sin Recursos secundarios que dependen del

recurso que se está definiendo.
Proporcione solo tipos de recursos que
permita el esquema del recurso principal.
La dependencia del recurso principal no
está implícita. Debe definirla explícitamente.
Consulte Establecimiento del nombre y el
tipo de recursos secundarios.
Salidas
En la sección de salidas, especifique valores que se devuelven de la implementación. Normalmente, devuelve valores de los
recursos implementados.
En el ejemplo siguiente se muestra la estructura de una definición de salida:
"outputs": {
"<output-name>" : {
"condition": "<boolean-value-whether-to-output-value>",
"type" : "<type-of-output-value>",
"value": "<output-value-expression>"
}
}
nombre de salida Sí Nombre del valor de salida. Debe ser un

identificador válido de JavaScript.
condition Sin Valor booleano que indica si se va a

devolver este valor de salida. Si es true ,
el valor se incluye en la salida de la
implementación. Si es false , el recurso
se omite en esta implementación. Si no se
especifica, el valor predeterminado es
true .
type Sí Tipo del valor de salida. Los valores de

salida admiten los mismos tipos que los
parámetros de entrada de plantilla. Si
especifica securestring para el tipo de
salida, el valor no se muestra en el historial
de implementación y no se puede
recuperar desde otra plantilla. Para usar un
valor de secreto en más de una plantilla,
almacene el secreto en un almacén de
claves y haga referencia al secreto en el
archivo de parámetros. Para más
información, consulte Uso de Azure Key
Vault para pasar el valor de parámetro
seguro durante la implementación.
value Sí Expresión de lenguaje de plantilla que se

evaluará y devolverá como valor de salida.
Para ejemplos sobre cómo usar las salidas, consulte Salidas en una plantilla de Azure Resource Manager.
Comentarios y metadatos
Tiene unas cuantas opciones para agregar comentarios y metadatos a la plantilla.
Comentarios
Para los comentarios en línea, puede usar // o /* ... */ , pero esta sintaxis no funciona con todas las herramientas. No
puede usar el editor de plantillas del portal para trabajar en plantillas con comentarios insertados. Si agrega este estilo de
comentarios, asegúrese de que las herramientas que use admitan los comentarios JSON insertados.
NOTE
Para implementar plantillas con comentarios mediante la CLI de Azure, debe usar el modificador --handle-extended-json-format .
{
"name": "[variables('vmName')]", // to customize name, change it in variables
"location": "[parameters('location')]", //defaults to resource group location
"apiVersion": "2018-10-01",
"dependsOn": [ /* storage account and network interface must be deployed first */
],
En Visual Studio Code, la extensión de herramientas de Azure Resource Manager puede detectar automáticamente una
plantilla de Resource Manager y cambiar el modo de lenguaje en consecuencia. Si ve Plantilla de Azure Resource
Manager en la esquina inferior derecha de VS Code, puede usar los comentarios en línea. Los comentarios insertados ya
no están marcados como no válidos.
Metadatos
Puede agregar un objeto metadata prácticamente en cualquier parte de la plantilla. Resource Manager omite el objeto,
pero el editor JSON puede advertirle de que la propiedad no es válida. En el objeto, defina las propiedades que necesita.
{
"metadata": {
"comments": "This template was developed for demonstration purposes.",
"author": "Example Name"
},
Para parameters, agregue un objeto metadata con una propiedad description .
"parameters": {
"adminUsername": {
"type": "string",
"metadata": {
"description": "User name for the Virtual Machine."
}
},
Al implementar la plantilla a través del portal, el texto que proporciona en la descripción se usa automáticamente como
sugerencia para ese parámetro.
Para resources, agregue un elemento comments o un objeto de metadatos. En el ejemplo siguiente se muestra un
elemento de comentarios y un objeto de metadatos.
"resources": [
{
"comments": "Storage account used to store VM disks",
"apiVersion": "2018-07-01",
"name": "[concat('storage', uniqueString(resourceGroup().id))]",
"metadata": {
"comments": "These tags are needed for policy compliance."
},
"tags": {
"Dept": "[parameters('deptName')]",
"Environment": "[parameters('environment')]"
},
"sku": {
},
"kind": "Storage",
"properties": {}
}
]
Para outputs, agregue un objeto de metadatos para el valor de salida.
"outputs": {
"hostname": {
"type": "string",
"value": "[reference(variables('publicIPAddressName')).dnsSettings.fqdn]",
"metadata": {
"comments": "Return the fully qualified domain name"
}
},
No se puede agregar un objeto de metadatos a las funciones definidas por el usuario.
Cadenas de varias líneas

Una cadena se puede dividir en varias líneas. Por ejemplo, la propiedad Location y uno de los comentarios del siguiente
ejemplo de JSON.
{
"name": "[variables('vmName')]", // to customize name, change it in variables
"location": "[
parameters('location')
]", //defaults to resource group location
"apiVersion": "2018-10-01",
/*
storage account and network interface
must be deployed first
*/
"dependsOn": [
],
Para implementar plantillas con cadenas de varias líneas mediante la CLI de Azure, debe usar el modificador
--handle-extended-json-format .
Pasos siguientes
Para ver plantillas completas de muchos tipos diferentes de soluciones, consulte Plantillas de inicio rápido de Azure.
Para obtener información detallada sobre las funciones que se pueden usar dentro de una plantilla, consulte Funciones
de plantilla de Azure Resource Manager.
Para combinar varias plantillas durante la implementación, consulte Uso de plantillas vinculadas con Azure Resource
Manager.
Para más recomendaciones sobre creación de platillas, consulte Azure Resource Manager template best practices
(Procedimientos recomendados para plantillas de Azure Resource Manager).
Para recomendaciones sobre cómo crear plantillas de Resource Manager que puede usar en todos los entornos de
Azure y Azure Stack, consulte Desarrollo de plantillas de Azure Resource Manager para mantener la coherencia en la
nube.
Preguntas más frecuentes sobre máquinas virtuales
Windows
En este artículo se responden algunas preguntas frecuentes que los usuarios plantean sobre las máquinas
virtuales Windows creadas en Azure mediante el modelo de implementación de Resource Manager. Para la
versión de Linux de este tema, vea Preguntas frecuentes sobre las máquinas virtuales de Linux.
¿Qué puedo ejecutar en una máquina virtual de Azure?

Todos los suscriptores pueden ejecutar software de servidor en una máquina virtual de Azure. Para saber más
sobre la directiva de soporte de software de servidor de Microsoft ejecutado en Azure, vea Soporte técnico del
software de servidor de Microsoft para máquinas virtuales de Microsoft Azure.
Existen determinadas versiones de Windows 7, Windows 8.1 y Windows 10 para suscriptores de ventajas de
MSDN Azure y suscriptores de pago por uso de desarrollo y prueba de MSDN, para tareas de desarrollo y
prueba. Para obtener más información, como instrucciones y limitaciones, consulte Imágenes de cliente de
Windows para los suscriptores de MSDN.
¿Cuánto almacenamiento puedo usar con una máquina virtual?

Cada disco de datos puede ser de hasta 32 767 GiB. El número de discos de datos que puede usar depende del
tamaño de la máquina virtual. Para obtener más información, consulte Tamaños de máquinas virtuales.
Azure Managed Disks son las nuevas ofertas de almacenamiento en disco recomendadas que se pueden usar con
Azure Virtual Machines para almacenar los datos de forma persistente. Puede usar varios de estos discos con cada
máquina virtual. Managed Disks ofrece dos tipos de opciones de almacenamiento duraderas: discos administrados
premium y estándar. Para más información, consulte los precios de Managed Disks.
Las cuentas de Azure Storage también pueden proporcionar almacenamiento para el disco del sistema operativo y
los discos de datos. Cada disco es un archivo .vhd almacenado como un blob en páginas. Para obtener información
detallada sobre los precios, consulte Detalles de precios de almacenamiento.
¿Cómo puedo tener acceso a mi máquina virtual?

Establezca una conexión remota mediante conexión a Escritorio remoto (RDP ) para una máquina virtual Windows.
Para obtener instrucciones, vea Conexión a una máquina virtual de Azure donde se ejecuta Windows e inicio de
sesión en ella. Se admite un máximo de 2 conexiones simultáneas, a menos que el servidor esté configurado como
un host de sesión de servicios de escritorio remoto.
Si tiene problemas con Escritorio remoto, consulte Solución de problemas de conexiones del Escritorio remoto a
una máquina virtual de Azure con Windows.
Si está familiarizado con Hyper-V, puede que esté buscando una herramienta similar a VMConnect. Azure no
ofrece una herramienta similar porque no admite el acceso de la consola a una máquina virtual.
¿Puedo usar el disco temporal (la unidad D: de forma predeterminada)

para almacenar datos?
No utilice el disco temporal para almacenar datos. Solo proporciona almacenamiento de forma temporal, por lo
que se arriesgaría a perder datos que no se pueden recuperar. La pérdida de datos puede ocurrir cuando se mueve
la máquina virtual a un host diferente. Cambiar el tamaño de una máquina virtual, actualizar el host o un error de
hardware en el host son algunas de las razones por las que se puede mover una máquina virtual.
Si tiene una aplicación que necesita usar la letra de unidad D:, puede reasignar las letras de unidad para que el
disco temporal utilice otra distinta a D:. Para obtener instrucciones, consulte Cambio de la letra de unidad del disco
temporal de Windows.
¿Cómo puedo cambiar la letra de la unidad del disco temporal?

Para cambiar la letra de la unidad, mueva el archivo de paginación y reasigne las letras de unidad; sin embargo,
debe asegurarse de realizar los pasos en un orden específico. Para obtener instrucciones, consulte Cambio de la
letra de unidad del disco temporal de Windows.
¿Puedo agregar una máquina virtual existente a un conjunto de

disponibilidad?
No. Si desea que la máquina virtual forme parte de un conjunto de disponibilidad, debe crearla dentro del
conjunto. Actualmente no es posible agregar una máquina virtual a un conjunto de disponibilidad una vez creada.
¿Puedo cargar una máquina virtual en Azure?

Sí. Para obtener instrucciones, consulte Migrating on-premises VMs to Azure (Migración de máquinas virtuales
locales a Azure).
¿Puedo cambiar el tamaño del disco del sistema operativo?

Sí. Para obtener instrucciones, consulte Cómo ampliar la unidad de sistema operativo de una máquina virtual en
un grupo de recursos de Azure.
¿Puedo copiar o clonar una máquina virtual de Azure existente?

Sí. Mediante el uso de imágenes administradas, puede crear una imagen de una máquina virtual y luego usar la
imagen para crear varias máquinas virtuales nuevas. Para obtener instrucciones, consulte Creación de una imagen
personalizada de una máquina virtual.
¿Por qué no veo las regiones de Canadá central y Canadá oriental por
medio de Azure Resource Manager?
Las dos nuevas áreas Canadá central y Canadá oriental no se registran automáticamente para la creación de
máquinas virtuales en las suscripciones de Azure existentes. Este registro se realizará automáticamente cuando se
implementa una máquina virtual mediante el Portal de Azure en cualquier otra región usando Azure Resource
Manager. Después de implementar una máquina virtual en cualquier otra región de Azure, las áreas nuevas
deberán estar disponibles para las máquinas virtuales siguientes.
¿Se admiten máquinas virtuales Linux en Azure?

Sí. Para crear rápidamente una máquina virtual Linux de prueba, consulte Creación de una máquina virtual de
Linux en Azure mediante el Portal.
¿Puedo agregar una NIC a mi máquina virtual después de crearla?

Sí, ahora es posible. En primer lugar, la máquina virtual debe detenerse desasignada. A continuación, puede
agregar o quitar una NIC (a menos que sea la última en la máquina virtual).
¿Hay algún requisito de nombre de equipo?

Sí. El nombre del equipo puede tener un máximo de 15 caracteres. Consulte el artículo sobre las convenciones y
restricciones de nomenclatura para más información sobre la denominación de los recursos.
¿Existen algunos requisitos para los nombres de grupos de recursos?

Sí. El nombre del grupo de recursos puede tener como máximo 90 caracteres. Consulte el artículo sobre las
convenciones y restricciones de nomenclatura para más información sobre los grupos de recursos.
¿Cuáles son los requisitos de nombre de usuario cuando se crea una

VM?
Los nombres de usuario pueden tener un máximo de 20 caracteres y no pueden terminar con un punto (".").
No se permiten los siguientes nombres de usuario:
administrator admin user user1
test user2 test1 user3
admin1 1 123 a
actuser adm admin2 aspnet
backup console david guest
john owner root server
sql support support_388945a0 sys
test2 test3 user4 user5
¿Cuáles son los requisitos de contraseña cuando se crea una VM?

Hay distintos requisitos de longitud de contraseña, en función de la herramienta que use:
Portal: entre 12 y 72 caracteres
PowerShell: entre 8 y 123 caracteres
CLI: entre 12 y 123
Deben incluir caracteres en minúsculas.
Deben incluir caracteres en mayúsculas.
Deben incluir un dígito.
Deben incluir un carácter especial (REGEX.MATCH [\W_]).
No se permiten las siguientes contraseñas:
abc@123 iloveyou! P@$$w0rd P@ssw0rd P@ssword123

Pa$$word pass@word1 Password! Password1 Password22

Creación de Máquinas Virtuales en Azure

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Creación de Máquinas Virtuales en Azure

Cargado por

Copyright:

Formatos disponibles

Contents

Documentación sobre máquinas virtuales Windows

¿Qué hay que considerar antes de crear una máquina virtual?

Azure PowerShell Use el comando Get-AzLocation.

API DE REST Use la operación para mostrar la lista de ubicaciones.

CLI de Azure Use la operaciónaz account list-locations.

Portal de Azure Los valores se especifican automáticamente cuando se

Azure PowerShell Get-AzVMImagePublisher -Location location

API de REST List image publishers (Lista de publicadores de imágenes)

CLI de Azure az vm image list-publishers --location ubicación

RESOURCE OBLIGATORIO DESCRIPCIÓN

Grupos de recursos Sí La máquina virtual debe encontrarse en

Cuenta de almacenamiento Sí La máquina virtual necesita la cuenta

Red virtual Sí La máquina virtual debe ser miembro

Dirección IP pública Sin La máquina virtual puede tener una

Interfaz de red Sí La máquina virtual necesita la interfaz

Discos de datos Sin La máquina virtual puede incluir discos

Portal de Azure Creación de una máquina virtual que ejecuta Windows en el

Plantillas Creación de una máquina virtual Windows con una plantilla

Azure PowerShell Creación de una máquina virtual Windows con PowerShell

SDK de cliente Implementación de recursos de Azure mediante C#

API de REST Create or update a VM (Creación o actualización de una

CLI de Azure Creación de una máquina virtual con la CLI de Azure

¿Cómo administro la máquina virtual que he creado?

Portal de Azure En el menú central, haga clic en Máquinas virtuales y

Azure PowerShell Para información sobre cómo usar PowerShell para

API DE REST Use la operación para obtener información sobre la máquina

SDK de cliente Para información sobre cómo usar C# para administrar

Inicio de sesión en la máquina virtual

Inicio de sesión en Azure

Crear máquina virtual

Conexión a la máquina virtual

Instalación del servidor web

Install-WindowsFeature -name Web-Server -IncludeManagementTools

Cuando haya terminado, cierre la conexión RDP con la máquina virtual.

Página principal de IIS

Inicio de Azure Cloud Shell

Creación de un grupo de recursos

New-AzResourceGroup -Name myResourceGroup -Location EastUS

Crear máquina virtual

Conexión a la máquina virtual

Get-AzPublicIpAddress -ResourceGroupName "myResourceGroup" | Select "IpAddress"

Instalación del servidor web

Install-WindowsFeature -name Web-Server -IncludeManagementTools

Cuando haya terminado, cierre la conexión RDP con la máquina virtual.

Visualización del servidor web en acción

Remove-AzResourceGroup -Name myResourceGroup

Inicio de Azure Cloud Shell

Crear un grupo de recursos

az group create --name myResourceGroup --location eastus

Crear máquina virtual

Apertura del puerto 80 para el tráfico web

az vm open-port --port 80 --resource-group myResourceGroup --name myVM

Conexión a la máquina virtual

Instalación del servidor web

Install-WindowsFeature -name Web-Server -IncludeManagementTools

Cuando haya terminado, cierre la conexión RDP con la máquina virtual.

Visualización del servidor web en acción

az group delete --name myResourceGroup

Inicio de Azure Cloud Shell

Creación de un grupo de recursos

Cree la máquina virtual con New -AzVM.

Conexión con una máquina virtual