initial commit
This commit is contained in:
OmkarDeshpande7
Binary file not shown.
|
After Width: | Height: | Size: 118 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 332 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 180 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 96 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 330 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 607 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 927 KiB |
@@ -0,0 +1 @@
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="-2.72 -1.34 120 60" width="120" height="60"><path d="M102.768 40.478c-1.87 0-3.452 1.5-3.452 3.38 0 1.798 1.5 3.38 3.38 3.38.288 0 .575-.072.647-.072l-1.87 2.59c-.072.072-.072.144-.072.216s.144.144.216.144h.575c.144 0 .36-.144.503-.216l2.66-3.74c.072-.144.216-.36.288-.432 0-.072.575-1.08.575-1.798-.072-1.942-1.5-3.452-3.452-3.452zm2.373 3.38c0 1.295-1.08 2.373-2.373 2.373s-2.373-1.08-2.373-2.373 1.08-2.373 2.373-2.373 2.373 1.08 2.373 2.373z" fill="#00aae7"/><path d="M34.087 40.982c-.072-.144-.144-.216-.216-.216h-.72c-.144 0-.216.144-.288.216l-4.17 8.846c-.072.072-.072.216-.072.288 0 0 .072.072.144.072h.863c.072 0 .216 0 .216-.072.072-.072.072-.144.072-.216l.863-1.87c.072-.072.072-.144.072-.144h5.178c.072 0 .072 0 .072.072l.935 1.942c.072.072.072.216.288.216h.863c.072 0 .144-.072.144-.072s.072-.072 0-.144zm1.582 5.825h-4.315l2.158-4.53zm-9.925 2.23h-4.962V40.9c0-.144-.072-.216-.216-.216h-.72c-.216 0-.216.072-.216.216v9c0 .144.072.216.216.216h5.825c.144 0 .216-.072.216-.216l-.072-.647c0-.072 0-.144-.072-.216zm-12.873-8.27H8.628c-.288 0-.288.144-.288.36v8.846c0 .072.072.144.216.144h.647c.144 0 .216-.072.216-.288v-3.812c0-.072 0-.144.144-.144h3.524c1.654 0 2.805-1.08 2.805-2.59 0-1.223-.935-2.517-3.02-2.517zm1.942 2.59c0 .79-.647 1.582-1.87 1.582H9.635c-.072 0-.144-.072-.144-.144v-2.95c0-.072.072-.072.072-.072h3.38c.647 0 1.15.216 1.438.503s.432.647.432 1.08zm33.37-2.66H38.69c-.144 0-.144.072-.144.216v.575c0 .144 0 .216.216.216h4.1v8.127c0 .144.072.216.216.216h.72c.144 0 .216-.072.216-.216v-8.055h4.1c.216 0 .216-.072.216-.216V40.9c.072-.216-.072-.216-.144-.216zm34.017 2.59c0-1.295-.935-2.59-3.02-2.59h-4.243c-.288 0-.288.216-.288.36V49.9c0 .144.072.216.216.216h.647c.144 0 .216-.072.216-.288v-3.812c0-.072 0-.144.144-.144h1.438c.36.503 2.086 2.517 3.308 4.027a.55.55 0 0 0 .36.144h.863s.36 0 .216-.144l-.144-.144-3.236-3.955h.575c1.798.144 2.95-.935 2.95-2.517zm-1.08.072c0 .79-.647 1.582-1.87 1.582h-3.308c-.072 0-.144-.072-.144-.144v-2.95c0-.072.072-.072.072-.072h3.38c.647 0 1.15.216 1.438.503s.432.647.432 1.08zm-22.222-2.517h-7.264a.31.31 0 0 0-.288.288v8.918c0 .144.072.216.144.216h.79c.072 0 .144-.072.144-.144v-4.027h5.466c.072 0 .144-.072.144-.144v-.72c0-.072-.072-.144-.144-.144h-5.466v-2.95c0-.072 0-.072.072-.072h6.4c.144 0 .216-.072.216-.216v-.647c0-.072 0-.144-.072-.144 0-.216-.072-.216-.144-.216zm35.96-.144h-.575c-.144 0-.216.072-.288.144l-3.524 3.596s-.072 0-.072-.072l-3.452-3.524s-.144-.072-.288-.072h-.575c-.072 0-.216 0-.216.216v9c0 .216.072.216.216.216h.72c.072 0 .216 0 .216-.216V42.78L90.1 45.8a.55.55 0 0 0 .36.144c.216 0 .36-.144.36-.144l3.092-3.092v7.264c0 .144.072.216.216.216h.79c.144 0 .216-.072.216-.216v-9c-.072-.072-.072-.216-.288-.288zm-28.623-.216c-2.877 0-5.178 2.23-5.178 4.962s2.3 4.962 5.178 4.962 5.178-2.23 5.178-4.962-2.3-4.962-5.178-4.962zm4.027 4.9c0 2.086-1.798 3.812-4.027 3.812s-4.027-1.726-4.027-3.812 1.798-3.812 4.027-3.812c2.23.072 4.027 1.726 4.027 3.812z" fill="#00000a"/><path d="M82.068 16.98l-7.633-3.127-9.196-3.678-7.817-3.22c-.184-.092-.276 0-.276 0l-7.725 3.127-1.38.552-6.437 2.667L32.4 16.98s-.092.092 0 .092l8.644 3.494 16.093 6.62h.276l16-6.53 8.644-3.494c.276-.092 0-.184 0-.184zm-10.483-3.127l-6.437 2.575-6.437-2.575 6.437-2.667zm-7.817 3.22L57.33 19.74l-6.437-2.575 6.437-2.667zM57.24 8.06l6.437 2.667-6.437 2.667-6.437-2.667zm-7.817 3.127l6.437 2.667-6.437 2.667-6.53-2.667zM35.17 17.073l6.437-2.575 6.437 2.667-6.437 2.575zm7.91 3.22l6.437-2.667 6.437 2.667-6.437 2.575zm14.162 5.793l-6.437-2.667 6.437-2.667 6.437 2.575zm7.91-3.22l-6.437-2.575 6.437-2.667 6.437 2.575zm7.91-3.22l-6.437-2.575 6.437-2.575 6.437 2.575z" fill="#00aae7"/><path d="M63.768 17.073L57.33 19.74l-6.437-2.667 6.437-2.667zm7.817 3.22l-6.437 2.575-6.437-2.575 6.437-2.667zm-7.91 3.22l-6.437 2.575-6.345-2.575 6.437-2.667z" fill="#008ccc"/><path d="M81.15 23.878l-24 9.84-24.093-9.84 7.91-3.22 16.093 6.62h.276l16-6.53z" fill="#007bb6"/><path d="M48.043 17.073l-6.437 2.667-6.437-2.667 6.345-2.667z" fill="#68cef2"/><path d="M55.86 20.292l-6.437 2.667-6.345-2.667 6.345-2.575z" fill="#008ccc"/><path d="M55.952 13.855l-6.53 2.667-6.437-2.667 6.437-2.667zm7.817-3.22l-6.437 2.667-6.437-2.667L57.24 8.06zm7.817 3.22l-6.437 2.667-6.437-2.667 6.437-2.575zm7.817 3.22l-6.345 2.575-6.437-2.575 6.345-2.667z" fill="#68cef2"/></svg>
|
||||
|
After Width: | Height: | Size: 4.2 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 299 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 286 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 120 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 257 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.1 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 69 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 81 KiB |
@@ -0,0 +1,81 @@
|
||||
---
|
||||
export interface Props {
|
||||
versions: string[];
|
||||
}
|
||||
const { versions } = Astro.props;
|
||||
---
|
||||
|
||||
<style>
|
||||
.iframe-container {
|
||||
position: relative;
|
||||
width: 100%;
|
||||
min-height: 80vh;
|
||||
aspect-ratio: 4 / 3;
|
||||
border: 1px solid var(--sl-color-gray-5);
|
||||
border-radius: 0.25rem;
|
||||
overflow: hidden;
|
||||
}
|
||||
#swagger-iframe {
|
||||
position: absolute;
|
||||
top: 0;
|
||||
left: 0;
|
||||
width: 100%;
|
||||
height: 100%;
|
||||
min-height: 80vh;
|
||||
border: none;
|
||||
}
|
||||
</style>
|
||||
|
||||
<div class="version-buttons">
|
||||
{versions.map(tag => (
|
||||
<button class="version-btn" data-src={`/vjailbreak/swagger-ui/${tag}/`}>{tag}</button>
|
||||
))}
|
||||
</div>
|
||||
<div class="iframe-container">
|
||||
<iframe id="swagger-iframe" title="Swagger API Reference" loading="lazy"></iframe>
|
||||
</div>
|
||||
|
||||
<script>
|
||||
document.addEventListener('DOMContentLoaded', () => {
|
||||
const container = document.querySelector('.version-buttons').parentElement;
|
||||
const buttons = container.querySelectorAll('.version-btn');
|
||||
const iframe = container.querySelector('#swagger-iframe');
|
||||
const iframeContainer = container.querySelector('.iframe-container');
|
||||
|
||||
function loadApiVersion(event) {
|
||||
buttons.forEach(btn => btn.classList.remove('active'));
|
||||
const clickedButton = event.currentTarget;
|
||||
clickedButton.classList.add('active');
|
||||
const newSrc = clickedButton.getAttribute('data-src');
|
||||
iframe.src = newSrc;
|
||||
}
|
||||
|
||||
buttons.forEach(button => {
|
||||
button.addEventListener('click', loadApiVersion);
|
||||
});
|
||||
|
||||
let defaultIdx = 0;
|
||||
let localStorageVersion = undefined;
|
||||
try {
|
||||
localStorageVersion = localStorage.getItem('vjailbreakSelectedVersion');
|
||||
} catch (e) {}
|
||||
if (localStorageVersion) {
|
||||
buttons.forEach((btn, idx) => {
|
||||
if (btn.textContent === localStorageVersion) {
|
||||
defaultIdx = idx;
|
||||
}
|
||||
});
|
||||
} else if (typeof defaultVersion !== 'undefined') {
|
||||
buttons.forEach((btn, idx) => {
|
||||
if (btn.textContent === defaultVersion) {
|
||||
defaultIdx = idx;
|
||||
}
|
||||
});
|
||||
}
|
||||
if (buttons.length > 0) {
|
||||
buttons[defaultIdx].click();
|
||||
} else if (iframeContainer) {
|
||||
iframeContainer.innerHTML = '<p>No API versions found.</p>';
|
||||
}
|
||||
});
|
||||
</script>
|
||||
@@ -0,0 +1,139 @@
|
||||
---
|
||||
const widths = ['0.5rem', '1rem', '1.5rem', '2rem', '2.5rem', '3rem', '4rem'];
|
||||
const heights = ['80%', '85%', '90%', '95%', '100%'];
|
||||
const anims = [
|
||||
['0s', '4s'],
|
||||
['-3s', '7s'],
|
||||
['-2s', '8s'],
|
||||
['-3s', '9s'],
|
||||
['-2s', '10s'],
|
||||
['-4s', '11s'],
|
||||
['-6s', '12s'],
|
||||
];
|
||||
const opacity = [
|
||||
'opacity-10',
|
||||
'opacity-20',
|
||||
'opacity-30',
|
||||
'opacity-40',
|
||||
'opacity-50',
|
||||
'opacity-60',
|
||||
'opacity-70',
|
||||
'opacity-80',
|
||||
'opacity-90',
|
||||
'opacity-100',
|
||||
];
|
||||
|
||||
const margins = ['0', '0.3rem', '1rem'];
|
||||
|
||||
interface Props {
|
||||
class?: string;
|
||||
bands?: number;
|
||||
}
|
||||
|
||||
const { bands = 40 } = Astro.props;
|
||||
//const validBands = Number.isInteger(bands) && bands > 0 ? bands : 5; // Ensure it's a valid number
|
||||
const slices = Array.from({ length: bands }).map((_, i) => {
|
||||
const opacityI =
|
||||
i < bands / 2
|
||||
? Math.ceil(i / 2)
|
||||
: bands - i < opacity.length
|
||||
? bands - i
|
||||
: Math.floor((Math.random() * opacity.length) / 2 + opacity.length / 2);
|
||||
|
||||
const anim = Math.floor(Math.random() * anims.length);
|
||||
|
||||
return {
|
||||
animationDelay: anims[anim][0],
|
||||
animationDuration: anims[anim][1],
|
||||
opacity: (opacityI + 1) / 15,
|
||||
marginRight: margins[Math.floor(Math.random() * margins.length)],
|
||||
height: heights[Math.floor(Math.random() * heights.length)],
|
||||
width: widths[Math.floor(Math.random() * widths.length)],
|
||||
};
|
||||
});
|
||||
---
|
||||
|
||||
<div class="not-content">
|
||||
<div class="aurora">
|
||||
{slices.map((slice, index) => (
|
||||
<div
|
||||
class="aurora-slice"
|
||||
style={{
|
||||
animationDelay: slice.animationDelay,
|
||||
animationDuration: slice.animationDuration,
|
||||
opacity: slice.opacity,
|
||||
marginRight: slice.marginRight,
|
||||
height: slice.height,
|
||||
width: slice.width,
|
||||
}}
|
||||
/>
|
||||
))}
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<style>
|
||||
.aurora {
|
||||
transform: perspective(600px) rotateX(-10deg) rotateY(-9deg);
|
||||
pointer-events: none;
|
||||
position: fixed;
|
||||
inset: 0;
|
||||
z-index: -10;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
width: 100%;
|
||||
height: 600px;
|
||||
filter: blur(1.5rem);
|
||||
}
|
||||
|
||||
@media (max-width: 60rem) {
|
||||
.aurora {
|
||||
filter: blur(1rem);
|
||||
}
|
||||
.aurora-slice:nth-child(odd) {
|
||||
display: none;
|
||||
}
|
||||
}
|
||||
|
||||
.aurora-slice {
|
||||
will-change: transform;
|
||||
animation-name: aurora;
|
||||
animation-timing-function: ease-in-out;
|
||||
animation-iteration-count: infinite;
|
||||
flex-grow: 1;
|
||||
background-image: linear-gradient(
|
||||
0deg,
|
||||
rgba(219, 39, 119, 0) 0%,
|
||||
rgba(4, 182, 212, 0.8) 4%,
|
||||
rgba(4, 182, 212, 0.6) 5%,
|
||||
rgba(234, 242, 166, 0.75) 8%,
|
||||
rgba(67, 183, 160, 0.4) 12%,
|
||||
rgba(219, 200, 219, 0.65) 22%,
|
||||
rgba(129, 39, 219, 0.55) 40%,
|
||||
rgba(219, 39, 119, 0) 100%
|
||||
);
|
||||
}
|
||||
|
||||
[data-theme='light'] .aurora-slice {
|
||||
background-image: linear-gradient(
|
||||
0deg,
|
||||
rgba(219, 39, 119, 0) 0%,
|
||||
rgba(4, 182, 212, 0.5) 4%,
|
||||
rgba(4, 182, 212, 0.35) 8%,
|
||||
rgba(67, 183, 160, 0.3) 18%,
|
||||
rgba(219, 200, 219, 0.15) 20%,
|
||||
rgba(219, 39, 119, 0.4) 40%,
|
||||
rgba(219, 39, 119, 0) 100%
|
||||
);
|
||||
}
|
||||
|
||||
|
||||
@keyframes aurora {
|
||||
0%,
|
||||
100% {
|
||||
transform: translateY(0);
|
||||
}
|
||||
50% {
|
||||
transform: translateY(10%);
|
||||
}
|
||||
}
|
||||
</style>
|
||||
@@ -0,0 +1,104 @@
|
||||
---
|
||||
import config from 'virtual:starlight/user-config';
|
||||
|
||||
import LanguageSelect from 'virtual:starlight/components/LanguageSelect';
|
||||
import Search from 'virtual:starlight/components/Search';
|
||||
import SiteTitle from 'virtual:starlight/components/SiteTitle';
|
||||
import SocialIcons from 'virtual:starlight/components/SocialIcons';
|
||||
import ThemeSelect from 'virtual:starlight/components/ThemeSelect';
|
||||
import GithubRelease from './githubRelease.astro';
|
||||
|
||||
/**
|
||||
* Render the `Search` component if Pagefind is enabled or the default search component has been overridden.
|
||||
*/
|
||||
const shouldRenderSearch =
|
||||
config.pagefind || config.components.Search !== '@astrojs/starlight/components/Search.astro';
|
||||
---
|
||||
|
||||
<div class="header sl-flex">
|
||||
<div class="title-wrapper sl-flex">
|
||||
<SiteTitle />
|
||||
</div>
|
||||
<div class="sl-flex print:hidden">
|
||||
{shouldRenderSearch && <Search />}
|
||||
</div>
|
||||
<div class="sl-hidden md:sl-flex print:hidden right-group">
|
||||
<div class="sl-flex social-icons">
|
||||
<SocialIcons />
|
||||
</div>
|
||||
<div class="sl-flex release-dropdown">
|
||||
<GithubRelease />
|
||||
</div>
|
||||
<ThemeSelect />
|
||||
<LanguageSelect />
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<style>
|
||||
.header {
|
||||
gap: var(--sl-nav-gap);
|
||||
justify-content: space-between;
|
||||
align-items: center;
|
||||
height: 100%;
|
||||
}
|
||||
|
||||
.title-wrapper {
|
||||
/* Prevent long titles overflowing and covering the search and menu buttons on narrow viewports. */
|
||||
overflow: clip;
|
||||
/* Avoid clipping focus ring around link inside title wrapper. */
|
||||
padding: 0.25rem;
|
||||
margin: -0.25rem;
|
||||
min-width: 0;
|
||||
}
|
||||
|
||||
.right-group,
|
||||
.social-icons {
|
||||
gap: 1rem;
|
||||
align-items: center;
|
||||
}
|
||||
.social-icons::after {
|
||||
content: '';
|
||||
height: 2rem;
|
||||
border-inline-end: 1px solid var(--sl-color-gray-5);
|
||||
}
|
||||
.release-dropdown {
|
||||
gap: 1rem;
|
||||
align-items: center;
|
||||
}
|
||||
.release-dropdown::after {
|
||||
content: '';
|
||||
height: 2rem;
|
||||
border-inline-end: 1px solid var(--sl-color-gray-5);
|
||||
}
|
||||
|
||||
@media (min-width: 50rem) {
|
||||
:global(:root[data-has-sidebar]) {
|
||||
--__sidebar-pad: calc(2 * var(--sl-nav-pad-x));
|
||||
}
|
||||
:global(:root:not([data-has-toc])) {
|
||||
--__toc-width: 0rem;
|
||||
}
|
||||
.header {
|
||||
--__sidebar-width: max(0rem, var(--sl-content-inline-start, 0rem) - var(--sl-nav-pad-x));
|
||||
--__main-column-fr: calc(
|
||||
(
|
||||
100% + var(--__sidebar-pad, 0rem) - var(--__toc-width, var(--sl-sidebar-width)) -
|
||||
(2 * var(--__toc-width, var(--sl-nav-pad-x))) - var(--sl-content-inline-start, 0rem) -
|
||||
var(--sl-content-width)
|
||||
) / 2
|
||||
);
|
||||
display: grid;
|
||||
grid-template-columns:
|
||||
/* 1 (site title): runs up until the main content column’s left edge or the width of the title, whichever is the largest */
|
||||
minmax(
|
||||
calc(var(--__sidebar-width) + max(0rem, var(--__main-column-fr) - var(--sl-nav-gap))),
|
||||
auto
|
||||
)
|
||||
/* 2 (search box): all free space that is available. */
|
||||
1fr
|
||||
/* 3 (right items): use the space that these need. */
|
||||
auto;
|
||||
align-content: center;
|
||||
}
|
||||
}
|
||||
</style>
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
import { Icon } from '@astrojs/starlight/components';
|
||||
---
|
||||
|
||||
<div class="read-more">
|
||||
<Icon class="icon" name="open-book" />
|
||||
<span><slot /></span>
|
||||
</div>
|
||||
|
||||
<style>
|
||||
.read-more {
|
||||
display: flex;
|
||||
gap: 0.5rem;
|
||||
align-items: flex-start;
|
||||
}
|
||||
.icon {
|
||||
--icon-size: 1.5rem;
|
||||
font-size: var(--icon-size);
|
||||
flex-shrink: 0;
|
||||
/* Align to the middle of the first line of text. */
|
||||
margin-block: calc((var(--sl-line-height) * 1rem - var(--icon-size)) / 2);
|
||||
color: var(--sl-color-text-accent);
|
||||
}
|
||||
</style>
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
interface Props {
|
||||
title?: string;
|
||||
}
|
||||
|
||||
const { title = "Powered by Platform9" } = Astro.props;
|
||||
---
|
||||
|
||||
<footer class="site-footer">
|
||||
<div class="footer-content">
|
||||
<slot />
|
||||
<div class="footer-info">
|
||||
<p>Built and maintained with ❤️ at <a href="https://platform9.com" class="footer-link">Platform9</a></p>
|
||||
</div>
|
||||
<div class="footer-brand" style="text-align: center;">
|
||||
<a href="https://platform9.com" class="footer-logo">
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="-2.72 -1.34 120 60" width="120" height="60"><path d="M102.768 40.478c-1.87 0-3.452 1.5-3.452 3.38 0 1.798 1.5 3.38 3.38 3.38.288 0 .575-.072.647-.072l-1.87 2.59c-.072.072-.072.144-.072.216s.144.144.216.144h.575c.144 0 .36-.144.503-.216l2.66-3.74c.072-.144.216-.36.288-.432 0-.072.575-1.08.575-1.798-.072-1.942-1.5-3.452-3.452-3.452zm2.373 3.38c0 1.295-1.08 2.373-2.373 2.373s-2.373-1.08-2.373-2.373 1.08-2.373 2.373-2.373 2.373 1.08 2.373 2.373z" fill="#00aae7"/><path d="M34.087 40.982c-.072-.144-.144-.216-.216-.216h-.72c-.144 0-.216.144-.288.216l-4.17 8.846c-.072.072-.072.216-.072.288 0 0 .072.072.144.072h.863c.072 0 .216 0 .216-.072.072-.072.072-.144.072-.216l.863-1.87c.072-.072.072-.144.072-.144h5.178c.072 0 .072 0 .072.072l.935 1.942c.072.072.072.216.288.216h.863c.072 0 .144-.072.144-.072s.072-.072 0-.144zm1.582 5.825h-4.315l2.158-4.53zm-9.925 2.23h-4.962V40.9c0-.144-.072-.216-.216-.216h-.72c-.216 0-.216.072-.216.216v9c0 .144.072.216.216.216h5.825c.144 0 .216-.072.216-.216l-.072-.647c0-.072 0-.144-.072-.216zm-12.873-8.27H8.628c-.288 0-.288.144-.288.36v8.846c0 .072.072.144.216.144h.647c.144 0 .216-.072.216-.288v-3.812c0-.072 0-.144.144-.144h3.524c1.654 0 2.805-1.08 2.805-2.59 0-1.223-.935-2.517-3.02-2.517zm1.942 2.59c0 .79-.647 1.582-1.87 1.582H9.635c-.072 0-.144-.072-.144-.144v-2.95c0-.072.072-.072.072-.072h3.38c.647 0 1.15.216 1.438.503s.432.647.432 1.08zm33.37-2.66H38.69c-.144 0-.144.072-.144.216v.575c0 .144 0 .216.216.216h4.1v8.127c0 .144.072.216.216.216h.72c.144 0 .216-.072.216-.216v-8.055h4.1c.216 0 .216-.072.216-.216V40.9c.072-.216-.072-.216-.144-.216zm34.017 2.59c0-1.295-.935-2.59-3.02-2.59h-4.243c-.288 0-.288.216-.288.36V49.9c0 .144.072.216.216.216h.647c.144 0 .216-.072.216-.288v-3.812c0-.072 0-.144.144-.144h1.438c.36.503 2.086 2.517 3.308 4.027a.55.55 0 0 0 .36.144h.863s.36 0 .216-.144l-.144-.144-3.236-3.955h.575c1.798.144 2.95-.935 2.95-2.517zm-1.08.072c0 .79-.647 1.582-1.87 1.582h-3.308c-.072 0-.144-.072-.144-.144v-2.95c0-.072.072-.072.072-.072h3.38c.647 0 1.15.216 1.438.503s.432.647.432 1.08zm-22.222-2.517h-7.264a.31.31 0 0 0-.288.288v8.918c0 .144.072.216.144.216h.79c.072 0 .144-.072.144-.144v-4.027h5.466c.072 0 .144-.072.144-.144v-.72c0-.072-.072-.144-.144-.144h-5.466v-2.95c0-.072 0-.072.072-.072h6.4c.144 0 .216-.072.216-.216v-.647c0-.072 0-.144-.072-.144 0-.216-.072-.216-.144-.216zm35.96-.144h-.575c-.144 0-.216.072-.288.144l-3.524 3.596s-.072 0-.072-.072l-3.452-3.524s-.144-.072-.288-.072h-.575c-.072 0-.216 0-.216.216v9c0 .216.072.216.216.216h.72c.072 0 .216 0 .216-.216V42.78L90.1 45.8a.55.55 0 0 0 .36.144c.216 0 .36-.144.36-.144l3.092-3.092v7.264c0 .144.072.216.216.216h.79c.144 0 .216-.072.216-.216v-9c-.072-.072-.072-.216-.288-.288zm-28.623-.216c-2.877 0-5.178 2.23-5.178 4.962s2.3 4.962 5.178 4.962 5.178-2.23 5.178-4.962-2.3-4.962-5.178-4.962zm4.027 4.9c0 2.086-1.798 3.812-4.027 3.812s-4.027-1.726-4.027-3.812 1.798-3.812 4.027-3.812c2.23.072 4.027 1.726 4.027 3.812z" fill="#00000a"/><path d="M82.068 16.98l-7.633-3.127-9.196-3.678-7.817-3.22c-.184-.092-.276 0-.276 0l-7.725 3.127-1.38.552-6.437 2.667L32.4 16.98s-.092.092 0 .092l8.644 3.494 16.093 6.62h.276l16-6.53 8.644-3.494c.276-.092 0-.184 0-.184zm-10.483-3.127l-6.437 2.575-6.437-2.575 6.437-2.667zm-7.817 3.22L57.33 19.74l-6.437-2.575 6.437-2.667zM57.24 8.06l6.437 2.667-6.437 2.667-6.437-2.667zm-7.817 3.127l6.437 2.667-6.437 2.667-6.53-2.667zM35.17 17.073l6.437-2.575 6.437 2.667-6.437 2.575zm7.91 3.22l6.437-2.667 6.437 2.667-6.437 2.575zm14.162 5.793l-6.437-2.667 6.437-2.667 6.437 2.575zm7.91-3.22l-6.437-2.575 6.437-2.667 6.437 2.575zm7.91-3.22l-6.437-2.575 6.437-2.575 6.437 2.575z" fill="#00aae7"/><path d="M63.768 17.073L57.33 19.74l-6.437-2.667 6.437-2.667zm7.817 3.22l-6.437 2.575-6.437-2.575 6.437-2.667zm-7.91 3.22l-6.437 2.575-6.345-2.575 6.437-2.667z" fill="#008ccc"/><path d="M81.15 23.878l-24 9.84-24.093-9.84 7.91-3.22 16.093 6.62h.276l16-6.53z" fill="#007bb6"/><path d="M48.043 17.073l-6.437 2.667-6.437-2.667 6.345-2.667z" fill="#68cef2"/><path d="M55.86 20.292l-6.437 2.667-6.345-2.667 6.345-2.575z" fill="#008ccc"/><path d="M55.952 13.855l-6.53 2.667-6.437-2.667 6.437-2.667zm7.817-3.22l-6.437 2.667-6.437-2.667L57.24 8.06zm7.817 3.22l-6.437 2.667-6.437-2.667 6.437-2.575zm7.817 3.22l-6.345 2.575-6.437-2.575 6.345-2.667z" fill="#68cef2"/></svg>
|
||||
</a>
|
||||
<p class="copyright">© 2025 Platform9 Systems, Inc. All Rights Reserved</p>
|
||||
</div>
|
||||
</div>
|
||||
</footer>
|
||||
|
||||
<style>
|
||||
.site-footer {
|
||||
margin-top: 4rem;
|
||||
padding: 3rem 1rem;
|
||||
border-top: 1px solid var(--sl-color-border);
|
||||
}
|
||||
|
||||
.footer-content {
|
||||
max-width: var(--sl-content-width);
|
||||
margin: 0 auto;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
.footer-brand {
|
||||
margin-bottom: 1.5rem;
|
||||
}
|
||||
|
||||
.footer-logo {
|
||||
display: inline-block;
|
||||
padding: 12px 24px;
|
||||
background: white;
|
||||
border-radius: 8px;
|
||||
}
|
||||
|
||||
.footer-logo img {
|
||||
height: 50px;
|
||||
display: block;
|
||||
}
|
||||
|
||||
[data-theme="dark"] .footer-logo {
|
||||
background: rgba(255, 255, 255, 0.9);
|
||||
}
|
||||
|
||||
.footer-info {
|
||||
color: var(--sl-color-gray-3);
|
||||
font-size: 0.9rem;
|
||||
line-height: 1.5;
|
||||
}
|
||||
|
||||
.copyright {
|
||||
margin-top: 0.5rem;
|
||||
}
|
||||
|
||||
:global(.footer-content p) {
|
||||
margin: 0.5rem 0;
|
||||
}
|
||||
|
||||
.footer-link {
|
||||
color: var(--sl-color-gray-3);
|
||||
text-decoration: none;
|
||||
transition: color 0.2s ease;
|
||||
}
|
||||
|
||||
.footer-link:hover {
|
||||
color: var(--sl-color-accent);
|
||||
}
|
||||
|
||||
</style>
|
||||
@@ -0,0 +1,110 @@
|
||||
---
|
||||
import '../styles/custom.css';
|
||||
// Fetch releases on the server-side
|
||||
const fetchReleases = async () => {
|
||||
const latestVersion = [{
|
||||
id: 0,
|
||||
name: "v0.1.7",
|
||||
html_url: "https://github.com/platform9/vjailbreak/releases/tag/v0.1.7"
|
||||
}];
|
||||
|
||||
try {
|
||||
const response = await fetch('https://api.github.com/repos/platform9/vjailbreak/releases');
|
||||
if (!response.ok) {
|
||||
console.error("Failed to fetch releases from GitHub.");
|
||||
return latestVersion;
|
||||
}
|
||||
const data = await response.json();
|
||||
return data.slice(0, 5);
|
||||
} catch (error) {
|
||||
console.error("Error fetching releases:", error);
|
||||
return latestVersion;
|
||||
}
|
||||
};
|
||||
|
||||
const releases = await fetchReleases();
|
||||
const latestRelease = releases[0]?.name || 'No releases available';
|
||||
const baseURL = Astro.site || '/'; // Fallback to '/' if Astro.site is undefined
|
||||
---
|
||||
|
||||
<!-- Dropdown -->
|
||||
<div class="select-container">
|
||||
<label for="release-select" class="select-label">Latest Release:</label>
|
||||
<select id="release-select" class="release-select">
|
||||
<option>Loading releases...</option>
|
||||
</select>
|
||||
</div>
|
||||
<script define:vars={{
|
||||
astroBaseURL: Astro.site || '/'
|
||||
}}>
|
||||
document.addEventListener('DOMContentLoaded', async () => {
|
||||
const CACHE_KEY = 'githubReleases';
|
||||
const CACHE_EXPIRY = 60 * 60 * 1000; // 1 hour
|
||||
const select = document.getElementById('release-select');
|
||||
|
||||
// Check cache first
|
||||
if (typeof window !== 'undefined' && window.localStorage) {
|
||||
const cachedReleases = localStorage.getItem(CACHE_KEY);
|
||||
const cacheExpiry = localStorage.getItem(`${CACHE_KEY}_expiry`);
|
||||
|
||||
if (cachedReleases && cacheExpiry && Date.now() < Number(cacheExpiry)) {
|
||||
try {
|
||||
console.debug("Reading releases from cache:", JSON.parse(cachedReleases)); // Debug log
|
||||
populateDropdown(JSON.parse(cachedReleases));
|
||||
return;
|
||||
} catch (e) {
|
||||
console.warn("Cache corrupted clearing", e);
|
||||
localStorage.removeItem(CACHE_KEY)
|
||||
localStorage.removeItem(`${CACHE_KEY}_expiry`)
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
try {
|
||||
console.debug("Fetching releases from GitHub"); // Debug log
|
||||
const response = await fetch('https://api.github.com/repos/platform9/vjailbreak/releases');
|
||||
const data = await response.json();
|
||||
const releases = data.slice(0, 5);
|
||||
|
||||
// Store in cache
|
||||
if (typeof window !== 'undefined' && window.localStorage) {
|
||||
localStorage.setItem(CACHE_KEY, JSON.stringify(releases));
|
||||
localStorage.setItem(`${CACHE_KEY}_expiry`, String(Date.now() + CACHE_EXPIRY));
|
||||
}
|
||||
|
||||
populateDropdown(releases);
|
||||
} catch (error) {
|
||||
console.error("Error fetching releases:", error);
|
||||
populateDropdown([{
|
||||
id: 0,
|
||||
name: "v0.1.7",
|
||||
html_url: "https://github.com/platform9/vjailbreak/releases/tag/v0.1.7"
|
||||
}]);
|
||||
}
|
||||
|
||||
function populateDropdown(releases) {
|
||||
const currentURL = astroBaseURL || window.location.origin; // Use Astro.site if available
|
||||
const pathPrefix = astroBaseURL ? '/vjailbreak/release_docs/' : '/release_docs/';
|
||||
select.innerHTML = releases.map(release => {
|
||||
const nameModified = release.name.replace(/\./g, '');
|
||||
const releaseDocsURL = `${currentURL}${pathPrefix}${nameModified}/`;
|
||||
return `<option value="${release.name}">${release.name}</option>`;
|
||||
}).join('');
|
||||
|
||||
select.selectedIndex = 0;
|
||||
|
||||
localStorage.setItem('vjailbreakSelectedVersion', select.value);
|
||||
select.onchange = (e) => {
|
||||
localStorage.setItem('vjailbreakSelectedVersion', e.target.value);
|
||||
|
||||
const version = e.target.value;
|
||||
const btns = document.querySelectorAll('.version-btn');
|
||||
btns.forEach(btn => {
|
||||
if (btn.textContent === version) {
|
||||
btn.click();
|
||||
}
|
||||
});
|
||||
};
|
||||
}
|
||||
});
|
||||
</script>
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
import { Icon } from '@astrojs/starlight/components';
|
||||
import '../styles/custom.css';
|
||||
---
|
||||
|
||||
<div class="slack-invite">
|
||||
<!-- Social Icons Slot -->
|
||||
<slot />
|
||||
|
||||
<!-- Slack Invite Button -->
|
||||
<button
|
||||
class="custom-icon-button"
|
||||
aria-label="Open Form"
|
||||
onclick="openModal()"
|
||||
>
|
||||
<Icon name="slack" style="--sl-icon-size: 1em;" fill="currentColor" color="var(--sl-color-text-accent)" />
|
||||
</button>
|
||||
|
||||
<!-- Modal Overlay -->
|
||||
<div id="modal-overlay" class="modal-overlay">
|
||||
<div class="modal-container">
|
||||
<div class="modal-header">
|
||||
<h3>Slack Invite</h3>
|
||||
<button class="modal-close" onclick="closeModal()">×</button>
|
||||
</div>
|
||||
<form
|
||||
action="https://docs.google.com/forms/u/0/d/e/1FAIpQLSel_cpjw-lfHSchLYE8KqLlcHC1reZdbb30-0J9R1xJECVzGw/formResponse"
|
||||
method="post"
|
||||
target="_blank"
|
||||
>
|
||||
<input
|
||||
autocomplete="email"
|
||||
name="emailAddress"
|
||||
placeholder="Your email"
|
||||
type="email"
|
||||
required
|
||||
/>
|
||||
<button type="submit">Invite Me!</button>
|
||||
</form>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<script>
|
||||
document.addEventListener('DOMContentLoaded', function () {
|
||||
const modalOverlay = document.getElementById('modal-overlay');
|
||||
|
||||
window.openModal = function () {
|
||||
modalOverlay.classList.add('active');
|
||||
};
|
||||
|
||||
window.closeModal = function () {
|
||||
modalOverlay.classList.remove('active');
|
||||
};
|
||||
|
||||
// Close modal on ESC key press
|
||||
document.addEventListener('keydown', function (event) {
|
||||
if (event.key === 'Escape' && modalOverlay.classList.contains('active')) {
|
||||
closeModal();
|
||||
}
|
||||
});
|
||||
});
|
||||
</script>
|
||||
@@ -0,0 +1,7 @@
|
||||
import { defineCollection } from 'astro:content';
|
||||
import { docsLoader } from '@astrojs/starlight/loaders';
|
||||
import { docsSchema } from '@astrojs/starlight/schema';
|
||||
|
||||
export const collections = {
|
||||
docs: defineCollection({ loader: docsLoader(), schema: docsSchema() }),
|
||||
};
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: Overview
|
||||
description: Overview of vJailbreak architecture
|
||||
---
|
||||
|
||||
|
||||
Below is high level architecture of how vJailbreak works. vJailbreak runs
|
||||
in a virtual machine in the target OpenStack environment. vJailbreak connects with VMware environment via vSphere APIs, using the VDDK library for the Standard copy method only. vJailbreak Accelerated Copy and Storage-Accelerated Copy transfer disk data without requiring VDDK. It also uses the OpenStack SDK to interact with the OpenStack environment and perform the necessary provisioning operations including creation of volumes, VMs.
|
||||
|
||||
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: Components
|
||||
description: Overview of vJailbreak components
|
||||
---
|
||||
|
||||
|
||||
Below is an overview of each component and its role in the migration process.
|
||||
|
||||
### v2v-helper
|
||||
The `v2v-helper` is the main application responsible for executing the migration process. It is designed to run as a pod within the vJailbreak virtual machine (VM) in the target OpenStack environment.
|
||||
|
||||
### UI
|
||||
The `UI` component provides a user-friendly interface for vJailbreak. It allows users to manage and monitor the migration process through an intuitive graphical interface.
|
||||
|
||||
### migration-controller
|
||||
The `migration-controller` is a Kubernetes controller that schedules and manages the migration tasks. It ensures that migrations are executed efficiently and in accordance with the defined policies.
|
||||
|
||||
### v2v-cli
|
||||
The `v2v-cli` is a command-line interface tool that can initiate the migration process. While it is available, it is not required in the current version of vJailbreak, as the primary interface is the UI.
|
||||
|
||||
By understanding these components, users can better appreciate the architecture and functionality of vJailbreak, enabling them to effectively manage and execute VM migrations.
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: vJailbreak VM
|
||||
description: Overview of vJailbreak VM
|
||||
---
|
||||
|
||||
As part of the deployment process, vJailbreak is shipped as a virtual machine (VM) that can be deployed in the target OpenStack environment. The VM is configured with the necessary resources, including sufficient memory and processing power, to handle the migration tasks efficiently.
|
||||
|
||||
The vJailbreak VM comes with a [k3s](https://k3s.io/) deployment that runs various components as pods. The components include the v2v-helper, UI, and migration-controller as described in the [components](../components/).
|
||||
|
||||
The vJailbreak VM can be scaled out to handle multiple migration tasks concurrently. This is achieved by deploying additional vJailbreak VMs in the target OpenStack environment. For more information on scaling vJailbreak, see the [scaling](../guides/scaling/) guide.
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,967 @@
|
||||
---
|
||||
title: Archived Releases
|
||||
description: Archived Release Notes for vJailbreak
|
||||
---
|
||||
|
||||
## v0.1.2
|
||||
### What's Changed
|
||||
* Upgrade min version to v0.1.1 by @tanaypf9 in https://github.com/platform9/vjailbreak/pull/71
|
||||
* Use version as tag for release event by @tanaypf9 in https://github.com/platform9/vjailbreak/pull/72
|
||||
* Added React Query to cache data, refactored MigrationForm component, and added error handling to MigrationForm by @knnguy in https://github.com/platform9/vjailbreak/pull/69
|
||||
* Add FAQs by @tanaypf9 in https://github.com/platform9/vjailbreak/pull/74
|
||||
* Fix for incomplete transfer of changed blocks by @tanaypf9 in https://github.com/platform9/vjailbreak/pull/75
|
||||
* Add Video Demo by @tanaypf9 in https://github.com/platform9/vjailbreak/pull/73
|
||||
* Add vCenter role perms and port req by @tanaypf9 in https://github.com/platform9/vjailbreak/pull/76
|
||||
* Adding additional network port prereqs for NBDkit by @jeremymv2 in https://github.com/platform9/vjailbreak/pull/77
|
||||
* replaced vCenter Role permissions with more comprehensive list from R… by @jeremymv2 in https://github.com/platform9/vjailbreak/pull/78
|
||||
* update README with table for prereqs by @jeremymv2 in https://github.com/platform9/vjailbreak/pull/79
|
||||
* Add debug logs to v2v-helper by @tanaypf9 in https://github.com/platform9/vjailbreak/pull/80
|
||||
* UI: Fixes by @knnguy in https://github.com/platform9/vjailbreak/pull/87
|
||||
* Remove unused VMInfo field by @tanaypf9 in https://github.com/platform9/vjailbreak/pull/82
|
||||
* Add ephemeral storage req and limits by @tanaypf9 in https://github.com/platform9/vjailbreak/pull/119
|
||||
* Compress nmcli scripts by @tanaypf9 in https://github.com/platform9/vjailbreak/pull/120
|
||||
* Wait for volume mount for up to a minute by @tanaypf9 in https://github.com/platform9/vjailbreak/pull/121
|
||||
* Disable healthchecks by default by @tanaypf9 in https://github.com/platform9/vjailbreak/pull/122
|
||||
* Update healthcheck in README by @tanaypf9 in https://github.com/platform9/vjailbreak/pull/124
|
||||
* Mapped OS_PROJECT_DOMAIN_NAME to OS_DOMAIN_NAME and OS_PROJECT_NAME t… by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/130
|
||||
* add IpAddress and VM state info to migrationtemplate status by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/133
|
||||
* 106 - disabled stopped VMs from migrating and notified with a tooltip by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/136
|
||||
* Allowed one to many network mappings from VMware to Openstack by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/137
|
||||
* UI: If the form is not submitted CRs created, should be deleted by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/139
|
||||
* UI: Handle VM refresh with additional put call to migration template and add adjust the timeout needed for it to reflect latest detail by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/142
|
||||
* check if disks have os installed in lexical order (release) by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/140
|
||||
|
||||
### Known Issues
|
||||
* If the VM to be migrated has an LV spanning multiple physical devices used as boot volume unless both are mounted simultaneously to the OS-VM, vJailbreak cannot detect whether it is bootable, or not. ([issue link](https://github.com/platform9/vjailbreak/issues/146))
|
||||
* If a user turns on a VM on VCenter after migration and tries to migrate it again, the migration object will not be created. In this case, the user should delete the VM from PCD/Openstack before trying the migration again. This error will be pushed up the stack for visibility.
|
||||
|
||||
### New Contributors
|
||||
* @patil-pratik-87 made their first contribution in https://github.com/platform9/vjailbreak/pull/130
|
||||
* @OmkarDeshpande7 made their first contribution in https://github.com/platform9/vjailbreak/pull/133
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.1.1...16.01
|
||||
|
||||
## v0.1.3
|
||||
### What's Changed
|
||||
* Fix ui to accept OS_INSECURE from rc file by @spai-p9 in https://github.com/platform9/vjailbreak/pull/177
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.1.2...v0.1.3
|
||||
|
||||
## v0.1.4
|
||||
### What's Changed
|
||||
* Fix GH workflow runs on release event by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/147
|
||||
* workflow dispatch manual by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/148
|
||||
* Update README.md by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/149
|
||||
* Update model.ts by @markp93 in https://github.com/platform9/vjailbreak/pull/152
|
||||
* Added delete migration functionality to the migration table by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/155
|
||||
* Adding workers nodes to the vjailbreak by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/161
|
||||
* update package.json by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/172
|
||||
* Update issue templates by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/158
|
||||
* Update bug_report.yaml by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/175
|
||||
* Migration data copy progress % and migration phases by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/167
|
||||
* Nit: consistent referring to company VMware by @ericwb in https://github.com/platform9/vjailbreak/pull/164
|
||||
* Update README.md by @markp93 in https://github.com/platform9/vjailbreak/pull/170
|
||||
* release version v0.1.4 (release) by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/196
|
||||
|
||||
### New Contributors
|
||||
* @markp93 made their first contribution in https://github.com/platform9/vjailbreak/pull/152
|
||||
* @ericwb made their first contribution in https://github.com/platform9/vjailbreak/pull/164
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.1.3...v0.1.4
|
||||
|
||||
## v0.1.5
|
||||
### What's Changed
|
||||
* Accept vmware and openstack creds via secert by @spai-p9 in https://github.com/platform9/vjailbreak/pull/228
|
||||
* Create and Reuse existing open stack and vmware creds with other mino… by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/237
|
||||
* Support OS installed on LV by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/227
|
||||
* Adding templates for github wiki by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/226
|
||||
* resolving lint issues by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/239
|
||||
* resolving lint issues by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/240
|
||||
* update image tag to v0.1.5 by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/242
|
||||
* Base documentation update for vJailbreak by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/243
|
||||
* Update checkout action to generate release notes by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/249
|
||||
* Update checkout action to generate release notes by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/250
|
||||
* Ingress changes to call k8s apis by @spai-p9 in https://github.com/platform9/vjailbreak/pull/252
|
||||
* Reformatted readme by @damian-pf9 in https://github.com/platform9/vjailbreak/pull/206
|
||||
|
||||
### New Contributors
|
||||
* @damian-pf9
|
||||
* @anmolsachan
|
||||
* @bhavin192
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.1.4...v0.1.5
|
||||
|
||||
## v0.1.6
|
||||
### What's Changed
|
||||
* Update the correct gh-pages by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/265
|
||||
* Update the correct icon for gh-pages by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/266
|
||||
* Update the correct version for gh-pages by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/267
|
||||
* Bug :: #269 :: Unable to use uppercase letters in a credential's name by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/273
|
||||
* fix insecure openstack authentication (release) by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/278
|
||||
* Fixed issues with openstack cred creation + validation by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/280
|
||||
|
||||
### New Contributors
|
||||
* @AbhijeetThakur made their first contribution in https://github.com/platform9/vjailbreak/pull/273
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.1.5...v0.1.6
|
||||
|
||||
## v0.1.7
|
||||
### What's Changed
|
||||
* Update video link to latest by @anmolsachan in https://github.com/platform9/vjailbreak/pull/290
|
||||
* fix readme for openstackcreds and vmware creds by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/288
|
||||
* ( release ) Change base image to ubuntu base image, reduced image size. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/286
|
||||
* Ignore Failed phase on retry by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/289
|
||||
* api cosmetic fixes by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/274
|
||||
* Support rollback for failed VM by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/300
|
||||
* check VM status before marking migration as complete by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/295
|
||||
* UI: Api cosmetic changes UI by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/297
|
||||
* UI: Fix active migration by @spai-p9 in https://github.com/platform9/vjailbreak/pull/304
|
||||
* fix mocks, unit tests by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/308
|
||||
* block openstackcreds deletion for master creds by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/303
|
||||
* UI: Implement a new credential addition workflow, and remove the creds addition from MigrationForm and Scaleup drawer by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/298
|
||||
* Easy debug config by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/287
|
||||
* resolved lint issues by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/311
|
||||
* 270 identically named source destination credentials arent displayed properly by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/312
|
||||
* Actions enhancement: Build and push on every PR raised to main or release branch. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/313
|
||||
* Heavily re-organized docs pages by @damian-pf9 in https://github.com/platform9/vjailbreak/pull/309
|
||||
* Update the docs github page by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/314
|
||||
* Sync VDDK across agents without any manual intervention by @spai-p9 in https://github.com/platform9/vjailbreak/pull/296
|
||||
* Fix versions and github actions by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/316
|
||||
* Fixed regression while updating cosmetic api changes, virtualmac… by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/317
|
||||
* 0.1.7 release fixes by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/318
|
||||
* Build: Fix CGO Linking for libnbd Library in Build Process (release) by @spai-p9 in https://github.com/platform9/vjailbreak/pull/315
|
||||
* fix migration status with random pod ref name by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/320
|
||||
* UI: Disable scale down of a node when active migration is going on by @spai-p9 in https://github.com/platform9/vjailbreak/pull/319
|
||||
* release: Fix github action when PR raised from release branch by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/323
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.1.6...v0.1.7
|
||||
|
||||
## v0.1.8
|
||||
### What's Changed
|
||||
* Release v0.1.7 by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/322
|
||||
* Update release notes by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/326
|
||||
* Updating the video by @roopakparikh in https://github.com/platform9/vjailbreak/pull/342
|
||||
* Update the readme to point to the 'Getting Started' by @roopakparikh in https://github.com/platform9/vjailbreak/pull/349
|
||||
|
||||
### New Contributors
|
||||
* @roopakparikh made their first contribution in https://github.com/platform9/vjailbreak/pull/342
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.1.6...v0.1.8
|
||||
|
||||
## v0.1.9
|
||||
### What's Changed
|
||||
* Backend: Add check if datacenter exists by @spai-p9 in https://github.com/platform9/vjailbreak/pull/368
|
||||
* Proxy env injection via configmap by @spai-p9 in https://github.com/platform9/vjailbreak/pull/364
|
||||
* removed creds from logs and Made changes to match OS_INSECURE value t… by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/379
|
||||
* vddk files check before migration ( release ) by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/375
|
||||
* Damian doc updates by @damian-pf9 in https://github.com/platform9/vjailbreak/pull/377
|
||||
* Doc: Inject any environment variables required by user into v2v-helper pod. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/381
|
||||
* Backend: Change ownership of /home/ubuntu/vmware-vix-disklib-distrib to ubuntu:ubuntu via init container. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/378
|
||||
* ensure correct permissions on shared vmwarelib directory for rsync ac… by @spai-p9 in https://github.com/platform9/vjailbreak/pull/383
|
||||
* Scaling doc update by @damian-pf9 in https://github.com/platform9/vjailbreak/pull/391
|
||||
* Backend: Remove logs in vmwaremachines by @spai-p9 in https://github.com/platform9/vjailbreak/pull/390
|
||||
|
||||
### New Contributors
|
||||
* @sarika-p9 made their first contribution in https://github.com/platform9/vjailbreak/pull/379
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.1.8...v0.1.9
|
||||
|
||||
## v0.1.10
|
||||
### What's Changed
|
||||
* added os icons in vms list table in Migrations by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/431
|
||||
* Backend change to block selection of vms without appropriate flavors in openstack by @spai-p9 in https://github.com/platform9/vjailbreak/pull/424
|
||||
* Backend:Retrieve correct network names from backing Network references instead of device summary by @spai-p9 in https://github.com/platform9/vjailbreak/pull/432
|
||||
* Backend: Improve the error handling and event reporting on these failures. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/411
|
||||
* Backend: Preserve the job logs. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/435
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.1.9...v0.1.10
|
||||
## v0.1.11
|
||||
|
||||
### What's Changed
|
||||
* added swagger ui for v0.1.9 and v0.1.10 by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/439
|
||||
* counter output for incremental copy by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/451
|
||||
* automated swagger ui at every push by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/450
|
||||
* Migration stuck in Pending on UI by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/459
|
||||
* Wait for volume attachements also to clear out. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/461
|
||||
* v2v-helper: Add check if subnet exists to avoid panic. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/460
|
||||
* enable openstack re-auth by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/464
|
||||
* use flavor id instead of name in label by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/465
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.1.10...v0.1.11
|
||||
## v0.1.12
|
||||
|
||||
### What's Changed
|
||||
* save migration debug logs at hostPath '/var/log/pf9' ( release ) by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/479
|
||||
* Add ons in v2v-helper for post-migration actions by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/490
|
||||
* Updated documentation for all external connectivity required for vjailbreak by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/467
|
||||
* Sync migration logs from worker to master ( release ) by @spai-p9 in https://github.com/platform9/vjailbreak/pull/494
|
||||
* User should be able to delete migration when in pending or any stage by @spai-p9 in https://github.com/platform9/vjailbreak/pull/511
|
||||
* added the admincutover option to the migration strategy by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/514
|
||||
* disabled migration form submission on enter key when text inputs are … by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/515
|
||||
* added insecure option to the vmware creds form by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/516
|
||||
* Add check from nova side also for volume dettach by @spai-p9 in https://github.com/platform9/vjailbreak/pull/480
|
||||
* Document: Add cbt privilege and flavor selection logic in Doc. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/502
|
||||
* Increase timeout for vm status to become active by @spai-p9 in https://github.com/platform9/vjailbreak/pull/525
|
||||
* create delete update vmwaremachines by @spai-p9 in https://github.com/platform9/vjailbreak/pull/523
|
||||
* fix build issue. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/526
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.1.11...v0.1.12
|
||||
## v0.1.13
|
||||
|
||||
### What’s Changed
|
||||
* vPwned: Rolling Conversion (release) by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/546
|
||||
* uncomment build-vpwned action by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/552
|
||||
* added the functionality to validate and assign/edit ips to/of the vms for rolling conversion by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/567
|
||||
* added the target cluster selections for migrations by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/573
|
||||
* convert PCD Cluster name to k8s compatible by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/576
|
||||
* fix issues when VM is attached to same network twice by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/579
|
||||
* Release v0.1.13 (release) by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/581
|
||||
* Add proxy for vjailbreak by @spai-p9 in https://github.com/platform9/vjailbreak/pull/562
|
||||
* add/update/edit os and flavors in vms list in rolling conversion by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/586
|
||||
* Add alpine docker image with rsync,coreutils in quay by @spai-p9 in https://github.com/platform9/vjailbreak/pull/590
|
||||
* DOC: Add doc for virtio drivers injection by the user by @spai-p9 in https://github.com/platform9/vjailbreak/pull/589
|
||||
* change from cloud-ctl to pcdctl by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/599
|
||||
* Change the base ubuntu image for vJailbreak qcow by @spai-p9 in https://github.com/platform9/vjailbreak/pull/598
|
||||
* Fix scale up by @spai-p9 in https://github.com/platform9/vjailbreak/pull/601
|
||||
* Fix cluster name by @spai-p9 in https://github.com/platform9/vjailbreak/pull/602
|
||||
* fix openstack volume sizes being smaller than original disk size by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/558
|
||||
* improved guestfish logging by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/565
|
||||
* Rolling Conversion UI changes by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/548
|
||||
* fix debug log file for migration re-runs by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/560
|
||||
* move os family selection to per VM basis by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/568
|
||||
* save disk space on vjb VM by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/571
|
||||
* Prebake components by @spai-p9 in https://github.com/platform9/vjailbreak/pull/574
|
||||
* Give users option to upload virtio drivers to a path in master and then propogate it down to agents by @spai-p9 in https://github.com/platform9/vjailbreak/pull/575
|
||||
* make delete migration-controller-manager pod work by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/572
|
||||
|
||||
#### Usability Enhancements and Stability Improvements
|
||||
|
||||
- **Rolling Conversion (Beta Availability)**
|
||||
The Rolling Conversion feature is now available as a beta release.
|
||||
|
||||
- **Pre-Packaged vJailbreak Image**
|
||||
A new vJailbreak image is now available, containing all required components pre-installed. This enhancement eliminates the need for internet access during installation, making it suitable for restricted network environments.
|
||||
|
||||
- **Support for Custom VirtIO Drivers**
|
||||
Users may now upload VirtIO drivers to a designated path. If present, these drivers will be utilized during the migration process. If absent, the system will default to downloading the necessary drivers from the internet, providing flexibility based on deployment conditions. https://github.com/platform9/vjailbreak/blob/main/docs/src/content/docs/guides/virtio_doc.md
|
||||
|
||||
- **Resolution of Pod Eviction Due to Disk Pressure**
|
||||
An issue causing pod eviction under disk pressure conditions has been resolved. This fix improves the reliability and stability of workloads during extended migration operations.
|
||||
|
||||
- **Enhanced Debug Logging**
|
||||
Debug logs have been improved to provide more comprehensive and structured output
|
||||
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.1.12...v0.1.13
|
||||
## v0.1.14
|
||||
|
||||
### What's Changed
|
||||
* revert the changes for duplicate networks by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/605
|
||||
* accept os_family correctly and override if present by @spai-p9 in https://github.com/platform9/vjailbreak/pull/607
|
||||
* support migration without a cluster on pcd by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/608
|
||||
* do not fail migrations for snapshot delettions by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/611
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.1.13...v0.1.14
|
||||
## v0.1.15
|
||||
|
||||
### What's Changed
|
||||
* fix part-to-dev input by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/614
|
||||
* Fix RC file parsing to support special characters in OpenStack credentials. by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/619
|
||||
* Made changes to the desination cluster selection by showing cred name… by @patil-pratik-87 n https://github.com/platform9/vjailbreak/pull/634
|
||||
* pcdclusters and tenant in UI (release) by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/633
|
||||
* Destination cluster dropdown changes for same id by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/636
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.1.14...v0.1.15
|
||||
## v0.2.0
|
||||
|
||||
### What's Changed
|
||||
* refactor: unify release notes workflow for both PR merges and direct releases by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/631
|
||||
* Update release notes for v0.1.14 by @github-actions[bot] in https://github.com/platform9/vjailbreak/pull/645
|
||||
* Update release notes for v0.1.15 by @github-actions[bot] in https://github.com/platform9/vjailbreak/pull/646
|
||||
* PR description for testing by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/647
|
||||
* configmap for current vjailbreak version (release) by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/632
|
||||
* Update docs from gh-pages by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/649
|
||||
* Updated VMware custom resource to capture RDM disk information in VM details by @rishabh625 in https://github.com/platform9/vjailbreak/pull/563
|
||||
* sanitize kubernetes label values by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/655
|
||||
* dynamic etc host entries for controller (release) by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/663
|
||||
* Added a new sidenav by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/664
|
||||
* rolling conversion validations by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/566
|
||||
* remove docs dir and optimize API doc generation by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/652
|
||||
* #667 Fixes the Rebase Action by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/668
|
||||
* Check the target IP Allocation Pool to determine if Source VM IP is Available and Handle Port Creation 409 Conflict (release) by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/662
|
||||
* fix docs for yamls by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/670
|
||||
* Validate Openstack creds only for same env by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/681
|
||||
* Delete the mastercreds for openstack by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/678
|
||||
* Bugsnag and sidenav enahancements by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/679
|
||||
* Delete VMware credentials stuck in Unknown state by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/683
|
||||
* Detect ubuntu vm's < 17.10 and appropriately handle the networking for the interfaces by @spai-p9 in https://github.com/platform9/vjailbreak/pull/674
|
||||
* Fixed issue where sidenav collapse icon was coming on top of the Migr… by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/695
|
||||
* v2v-helper: Add sled in the checks by @spai-p9 in https://github.com/platform9/vjailbreak/pull/694
|
||||
|
||||
### New Contributors
|
||||
* @rishabh625 made their first contribution in https://github.com/platform9/vjailbreak/pull/563
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.1.15...v0.2.0
|
||||
## v0.2.1
|
||||
|
||||
### What's Changed
|
||||
* Nit: readme by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/704
|
||||
* Backport: vPwned: fix condition trigger for vm migrations by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/682
|
||||
* GH actions for cross fork PRs by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/709
|
||||
* remove docker login for build only steps by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/717
|
||||
* add kubernetes dashboard by default to grafana by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/714
|
||||
* Add opensource.txt file,inject it into the vm and prebake virtio-drivers by @spai-p9 in https://github.com/platform9/vjailbreak/pull/718
|
||||
* Revert pr 662 by @spai-p9 @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/719
|
||||
* simplified the release notes workflow to update docs by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/710
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.2.0...v0.2.1
|
||||
## v0.3.0
|
||||
|
||||
### What's Changed
|
||||
* RDM disk migration from VMware to Openstack on Same SAN array - if RDM is attached to single VM by @rishabh625 in https://github.com/platform9/vjailbreak/pull/654
|
||||
* persist host dns by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/735
|
||||
* fix for long vm names by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/738
|
||||
* additional vm name changes (release) by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/746
|
||||
* process single VM at a time by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/749
|
||||
* Feature: add volume backend to openstackcreds custom resource by @rishabh625 in https://github.com/platform9/vjailbreak/pull/745
|
||||
* v2v-helper: log time taken by disk copy and conversion by @jessicaralhan in https://github.com/platform9/vjailbreak/pull/737
|
||||
* throttle goroutines by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/758
|
||||
* unblock vcenter with no clusters by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/755
|
||||
* added option to select security group by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/761
|
||||
* Delete rolling migration plan by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/754
|
||||
* Reset migrated status on migration object deletion by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/744
|
||||
* configurable vjb settings (release) by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/762
|
||||
* added amplitude changes by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/765
|
||||
* Adding time elapsed for migration and cluster conversions + fixed the … by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/767
|
||||
* Improve ESXi host configuration UX by removing selection confusion by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/757
|
||||
* Disconnect all Virtual NICs on VMWare Source VM upon successful migration by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/768
|
||||
* Backend: rhel family guest network ip retention ( release ) by @spai-p9 in https://github.com/platform9/vjailbreak/pull/766
|
||||
* v0.3.0 fixes for SG and os creds validation by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/773
|
||||
* fix ui for clusters by @spai-p9 in https://github.com/platform9/vjailbreak/pull/775
|
||||
* Fix time elapsed issue by @spai-p9 in https://github.com/platform9/vjailbreak/pull/776
|
||||
* fix for wait active timeout by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/777
|
||||
* fix vpwned unavailable issue by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/779
|
||||
* idle connection timeout for vcenter by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/781
|
||||
* revert back to metadata name by @spai-p9 in https://github.com/platform9/vjailbreak/pull/780
|
||||
|
||||
### New Contributors
|
||||
* @jessicaralhan made their first contribution in https://github.com/platform9/vjailbreak/pull/737
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.2.1...v0.3.0
|
||||
## v0.3.1
|
||||
|
||||
### What's Changed
|
||||
* Feature: Addition of rdm disk custom resource and controller by @rishabh625 in https://github.com/platform9/vjailbreak/pull/753
|
||||
* re-auth vcenter after timeout by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/787
|
||||
* reduce default vm scan concurrency, improve logging by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/791
|
||||
* Add fallback if /etc/os-release doesn't exist by @spai-p9 in https://github.com/platform9/vjailbreak/pull/772
|
||||
* bring back dhcp for non-matching subnets by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/795
|
||||
* amplitude and bugsnag keys (release) by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/769
|
||||
* fix vm refresh for new govomi clients by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/803
|
||||
* fix: one of the status.phase correctly renamed from pending to available by @rishabh625 in https://github.com/platform9/vjailbreak/pull/806
|
||||
* Add vjailbreak-settings.yaml ( release ) by @spai-p9 in https://github.com/platform9/vjailbreak/pull/808
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.3.0...v0.3.1
|
||||
## v0.3.2
|
||||
|
||||
### What's Changed
|
||||
* handle for sles by @spai-p9 in https://github.com/platform9/vjailbreak/pull/815
|
||||
* make the power off live vms default when selected and add completed at column. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/813
|
||||
* UI: Do admin cutover via UI by @spai-p9 in https://github.com/platform9/vjailbreak/pull/810
|
||||
* Added polling for QCOW2 image before docs update by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/804
|
||||
* add a setting to keep the copied volumes in case of failure by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/823
|
||||
* optimisations for openstack creds upload time by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/829
|
||||
* fix dasboard count mismatch by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/826
|
||||
* optimise disk pressure problem due to logs by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/832
|
||||
* In-place upgrade by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/792
|
||||
* Filtering security group according to particular tenant by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/824
|
||||
* change completed at to created at by @spai-p9 in https://github.com/platform9/vjailbreak/pull/835
|
||||
* Support Dynamic Hotplug-Enabled Flavors in Target Openstack Environment by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/838
|
||||
* crd update and ui changes required for hotplug by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/842
|
||||
* indicate missing base flavor for specific vmwaremachine by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/843
|
||||
* search option(s) for faster migration triggers by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/844
|
||||
* Fix label getting triggered back to no, when patched by @spai-p9 in https://github.com/platform9/vjailbreak/pull/847
|
||||
* Push things to S3 and introduce nightly builds (release) by @sharma-tapas @sarika-p9 in https://github.com/platform9/vjailbreak/pull/793
|
||||
* search for volume types and networks by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/849
|
||||
* added alert in the ui while upgrade in progress by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/850
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.3.1...v0.3.2
|
||||
## v0.3.3
|
||||
|
||||
### What's Changed
|
||||
* Fixed artifacts availability check by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/851
|
||||
* fill networks based on network devices by @spai-p9 in https://github.com/platform9/vjailbreak/pull/846
|
||||
* equate mac id case insensitive by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/857
|
||||
* get bootable index for windows LDM by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/855
|
||||
* Added MAX Keys to hotplug metadata and made it specific to PCD by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/860
|
||||
* UI and backend for multiple ip by @spai-p9 in https://github.com/platform9/vjailbreak/pull/833
|
||||
* Fix admin cutover by @spai-p9 in https://github.com/platform9/vjailbreak/pull/862
|
||||
* locked versions for nbdkit by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/865
|
||||
* fetch rpm from main by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/870
|
||||
* Fixed the os assigment in the migration form by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/867
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.3.2...v0.3.3
|
||||
## v0.3.4
|
||||
|
||||
### What's Changed
|
||||
* volume wait interval through settings by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/872
|
||||
* logs all openstack calls that we make by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/873
|
||||
* admin cut over poweroff sequence prevent user error by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/874
|
||||
* Added cronjob to fetch for latest release and notify in UI by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/882
|
||||
* bugfix: Add logic to assign IP from network interfaces if not already… by @rishabh625 in https://github.com/platform9/vjailbreak/pull/895
|
||||
* create openstack ports before copy by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/879
|
||||
* Admin cutover improve the pod label watch function by @spai-p9 in https://github.com/platform9/vjailbreak/pull/881
|
||||
* remove --delete to not purge each others logs in master by @spai-p9 in https://github.com/platform9/vjailbreak/pull/904
|
||||
* Advance option in UI to ask for fallback to DHCP if static IP assignment fails by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/906
|
||||
* block on channel send to ensure initial label delivery by @spai-p9 in https://github.com/platform9/vjailbreak/pull/900
|
||||
* Support for shared pRDM disk migration in vJailbreak, including all necessary controller changes and validation through testing with clustered Windows VMs using RDM disks by @rishabh625 in https://github.com/platform9/vjailbreak/pull/858
|
||||
* Optimize OpenstackCreds reconciliation for scalability by @spai-p9 in https://github.com/platform9/vjailbreak/pull/908
|
||||
* Change implementation from select to normal blocking channel. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/917
|
||||
* bugfix: Add check for RDM disks in VM migration validation by @rishabh625 in https://github.com/platform9/vjailbreak/pull/915
|
||||
* Added option in UI to retry Failed migrations by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/918
|
||||
* changed MAAS to Bare-metal by @sarika-p9 in https://github.com/platform9/vjailbreak/pull/916
|
||||
* Added static RPMs and versionlocked in dnf by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/921
|
||||
* Add SELinux for nbdkit by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/923
|
||||
* vmdataexporter cli arg validation by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/884
|
||||
* Fixed fonts inconsistency in vJailbreak UI by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/898
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.3.3...v0.3.4
|
||||
## v0.3.5
|
||||
|
||||
### What's Changed
|
||||
* Cache OpenStack instance metadata for performance and reliability by @spai-p9 in https://github.com/platform9/vjailbreak/pull/913
|
||||
* disabled upgrade button while migrations are in progress by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/934
|
||||
* disabled docs update workflow to run on release event by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/935
|
||||
* Updated CRD Upgrade logic with missing permissions by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/933
|
||||
* Bugfix: Added vmwaresession logged out, after retrieving data from vmware by @rishabh625 in https://github.com/platform9/vjailbreak/pull/939
|
||||
* Changed description of a advanced option - Fallback to DHCP by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/948
|
||||
* feat: View Migration pod logs from UI by @rishabh625 in https://github.com/platform9/vjailbreak/pull/942
|
||||
* Add support to display rdm disk and populate rdm disk details in UI by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/926
|
||||
* Refactor : VMwareMachine retrieval and validation in migration plan reconciliation by @rishabh625 in https://github.com/platform9/vjailbreak/pull/947
|
||||
* Custom header for a vjailbreak deployment through configmap by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/958
|
||||
* add creds requeue config to vjailbreak settings by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/965
|
||||
* feat: Implement RDM disks validation and query integration in migration workflow by @rishabh625 in https://github.com/platform9/vjailbreak/pull/963
|
||||
* feat: Set owner reference for RDM disks to ensure proper deletion with VMwareCreds by @rishabh625 in https://github.com/platform9/vjailbreak/pull/967
|
||||
* feat: Enhance RDM validation to include configuration checks and improve error messaging by @rishabh625 in https://github.com/platform9/vjailbreak/pull/972
|
||||
* fix: Update RDM disk migration retry logic and error handling by @rishabh625 in https://github.com/platform9/vjailbreak/pull/970
|
||||
* Add a default password for Ubuntu user that needs to be changed on first boot by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/976
|
||||
* List udev/fstab rules to preserve device mapping after migrations by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/905
|
||||
* Disable selection of older date and time while scheduling cutover by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/960
|
||||
* tls: remove cert trust logic, rely on OS_INSECURE for skipping verification by @jessicaralhan in https://github.com/platform9/vjailbreak/pull/863
|
||||
* change controller rollout policy to re-create by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/979
|
||||
* Fixed the bug where the script was not passed to the backend + update… by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/980
|
||||
* feat: Enhance RDM disk info population by validating disk name before updating volume reference by @rishabh625 in https://github.com/platform9/vjailbreak/pull/984
|
||||
* disabled log icon in ui (release) by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/986
|
||||
* disabled rdm config in UI (release) by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/987
|
||||
* enable k3s encryption at rest by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/990
|
||||
* Added htpasswd based authentification for ui by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/994
|
||||
* cache cred info for UI by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/996
|
||||
* Removed secrets GET calls from UI by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/995
|
||||
* Added command line utility to change and manage the user credentials for UI by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1002
|
||||
* bugfix: add limit to log streaming - limit number of bytes by @rishabh625 in https://github.com/platform9/vjailbreak/pull/988
|
||||
* Implemented automated HTTPS with Cert-Manager (release) by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1005
|
||||
* removed nonce from CSP by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1006
|
||||
* Vjbctl - utility to add and manage users by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1003
|
||||
* Vjbctl by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1010
|
||||
* cronjob fix by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1013
|
||||
* Add host entries to migration-vpwned-ingress by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1015
|
||||
* Implemented HTTPS with Cert-Manager by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1021
|
||||
* Updated default username from ubuntu to admin by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1023
|
||||
* added --no-restart to the utility to vjbctl by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1024
|
||||
* fixed count of selected vm by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1022
|
||||
* Custom title on browser tab for each vjailbreak VM deployment by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1026
|
||||
|
||||
### New Contributors
|
||||
* @meghansh-pf9 made their first contribution in https://github.com/platform9/vjailbreak/pull/958
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.3.4...v0.3.5
|
||||
## v0.3.6
|
||||
|
||||
### What's Changed
|
||||
* fix - Migration only takes the first subnet while creating the ports by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1019
|
||||
* Bugfix: sync annotation from VMware to RDM disk openstack volume reference if changed by @rishabh625 in https://github.com/platform9/vjailbreak/pull/993
|
||||
* Added vjailbreak-settings ConfigMap and implement RDM owner VM validation toggle by @rishabh625 in https://github.com/platform9/vjailbreak/pull/953
|
||||
* bugfix: previous PR introduced a issue where importToCinder was not g… by @rishabh625 in https://github.com/platform9/vjailbreak/pull/1033
|
||||
* Fix - blocking port creation if dhcp is selected but VM doesn't have a valid IP by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1047
|
||||
* Version Checker Cronjob exits gracefully in air-gapped environments by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1045
|
||||
* enabled rdm configuration button by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1041
|
||||
* bugfix: fix ImportToCinder to true from migrationplan controller by @rishabh625 in https://github.com/platform9/vjailbreak/pull/1038
|
||||
* Added filter on migrations based on current status and current creation time by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/944
|
||||
* Blocked migration of VM having unknown OS by @patil-pratik-87 in https://github.com/platform9/vjailbreak/pull/1042
|
||||
* Skip CopyingChagedBlocks phase when migration type is cold by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1055
|
||||
* fix: changing from patch to update while modifying importToCinder fieeld of RDM CR, adding idempotent guard and retry on conflict.. by @rishabh625 in https://github.com/platform9/vjailbreak/pull/1054
|
||||
* delete firstboot configmap when migration is deleted by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1071
|
||||
* Sv/issue 920/enhancements log collector bundle by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1063
|
||||
* added FQDN tooltip for better user guidance by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1069
|
||||
* bugfix: Handle VMware login failures gracefully without requeuing by @rijojohn85 in https://github.com/platform9/vjailbreak/pull/1061
|
||||
* Admin Cutover Periodic sync by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1056
|
||||
* fix - Delay in password expiration after creating the vjailbreak vm upon first login by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1076
|
||||
* Implement VM OS type validation in migration plan (release) by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1044
|
||||
* Cluster-Based VM Filtering in Migration Form by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/964
|
||||
* fix(airgap): Pre-bake cert-manager images by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1087
|
||||
* Show tenant name in openstack cluster name by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1085
|
||||
* Handle inconsistent types in Host API response by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1099
|
||||
* Separate Periodic Sync Interval Configuration for different migrations by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1083
|
||||
* Add DeepWiki badge to README by @roopakparikh in https://github.com/platform9/vjailbreak/pull/1107
|
||||
* Fix: Display RDM disk sizes correctly for disks smaller than 1 GB by @rijojohn85 in https://github.com/platform9/vjailbreak/pull/1090
|
||||
* fix: issue-1073 Removing password log and replacing with "REDACTED" echo by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1064
|
||||
* #1067 :: Remove unnecessary get migration calls on UI by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1103
|
||||
* Added Pre-migration check to see if port is available before migration by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1115
|
||||
* Fix: Prevent race condition in RDMDisk controller causing duplicate Cinder volume imports by @rijojohn85 in https://github.com/platform9/vjailbreak/pull/1086
|
||||
* [UI] Need a Global settings page by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1114
|
||||
* Remove race condition in credential deletion flow by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1116
|
||||
* Removed retry on failure checkbox by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1118
|
||||
* Added powershell scripts for firstboot by @amar-chand in https://github.com/platform9/vjailbreak/pull/945
|
||||
* mark migrationplan as successful if there are no VMs to migrate by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1123
|
||||
* fix deleted creds used in migrationtemplate and migrationplan by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1127
|
||||
* Resolve race condition and remove RDM sleep delay by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1125
|
||||
* Added Retry Mechanism in Periodic Sync by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1080
|
||||
* 1017 assigned ip for all vms removed if we select os of one of the vms post assigning ip by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1128
|
||||
* Added a new option to enter Periodic Sync interval by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1126
|
||||
* add proxy env set by user in controller as well by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1135
|
||||
* do not wait for status after sumitting migrationform by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1132
|
||||
* Fix - User should not be able to submit migration if OS is not selected during cold migration by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1136
|
||||
* powering on of cold migration vms fix by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1131
|
||||
* #1104 :: Bug :: Filter box for tenant search is going out of focus by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1138
|
||||
* #989 :: Bug :: VM search box is going out of focus on start migration page by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1141
|
||||
* Implemented wait for RDM disks availability by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1142
|
||||
* fix - Periodic sync values are not being populated in the migration ConfigMap, causing periodic sync to be skipped by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1148
|
||||
* fix - Vm with multiple IPs on same MAC address (Tried with 2 IPs) are not getting 2nd IP on interface post migration by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1034
|
||||
* Added an enhancement to revalidate the creds whenever required by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1113
|
||||
* Added podfailed status check and reordered validation logic by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1151
|
||||
* #1137 :: Bug :: OpenStack “Validate IP” does not fail gracefully when receiving a 500 (Internal Server Error) response by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1147
|
||||
* #1144,#1145 :: periodic sync interval should not be a mandatory field on the migration form page by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1152
|
||||
* find the correct boot device without guestfish by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1133
|
||||
* Pass user-assigned IPs through MigrationPlan for cold migration by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1153
|
||||
* #864 :: Fixed multiple IP reset on OS selection by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1156
|
||||
* #1154 :: Convert the global settings page to a tabular format by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1162
|
||||
* Fetch resources post revalidation of credentials by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1161
|
||||
* Fix: Use proxy from ENV for creating net/http clients by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/1159
|
||||
* added edge cases for blocking plan to reconcile by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1163
|
||||
* bugfix: Add empty check by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1166
|
||||
* fix: #903 Using format() with timezone offset instead of ISOString() for a… by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1171
|
||||
* Add envFrom configmap and have logs in validate IP endpoint by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1172
|
||||
* #1129 :: Remove duplicate error text on credential creation failure by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1174
|
||||
* Format UI directory with prettier by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1170
|
||||
* Removed duplicate options in migration form by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1177
|
||||
* #1175 :: Periodic sync validation requires clicking outside the input box before the Start button becomes enabled/disabled, which leads to start migration enabled even with wrong value sometimes by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1179
|
||||
* In advanced option validation check only for granularoptions ignore rest by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1183
|
||||
* Fix sdk while adding logs and other details by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/1178
|
||||
* Added check to fallback to 5m if interval is less than 5m by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1187
|
||||
* #1181 :: UI: Move to folder cannot use anyother name, when clearing the vjailbreakedVMs it appears again by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1186
|
||||
* #1192 :: Bug: Migration Submit button is disabled when triggering admin cutover with periodic sync by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1197
|
||||
* Inject log_collector.sh into the VM by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1194
|
||||
* fix netplan upload for multi-disk VM by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1195
|
||||
* Update revalidation status correctly by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1205
|
||||
|
||||
### New Contributors
|
||||
* @rijojohn85 made their first contribution in https://github.com/platform9/vjailbreak/pull/1061
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.3.5...v0.3.6
|
||||
## v0.3.7
|
||||
|
||||
### What's Changed
|
||||
* fix - Periodic Sync Migration Fails on Transient Network Errors Instead of Retrying by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1204
|
||||
* Prebaked Openstack Cli inside the vjailbreak VM by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1211
|
||||
* fix - Migration controller logs are being flooded by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1212
|
||||
* #1202 :: Bug :: Single migrationtemplate object should be created for one migrationplan (Use Dynamic Hotplug-Enabled Flavors is the advance option making post calls) by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1215
|
||||
* #1140 :: Enhancement :: Allow user input for IP's for any VM being migrated by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1217
|
||||
* Added migration pod and controller logs in the UI by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1214
|
||||
* #1040 :: Bug :: UI should block migration of VM having unknown OS (Should provide an option to select OS) by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1222
|
||||
* Backend implementation for ability to add server group to the VMs by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1219
|
||||
* Frontend for selecting server group during migration by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1220
|
||||
* [Fix] added APIReader to get RDM by @rijojohn85 in https://github.com/platform9/vjailbreak/pull/1149
|
||||
* cluster conversion fixes for static esx IPs by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1203
|
||||
* fix - Password set in cloud init is not being reflected by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1226
|
||||
* add more aggressive cleaning in v2v-helper by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1235
|
||||
* support gpu flavours by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1233
|
||||
* Show correct time elapsed during migration on ui by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1237
|
||||
* Removed fstrim by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1143
|
||||
* Reduced log verbosity for disk copy by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1249
|
||||
* Disable 'Apply Changes' button when ip has invalid format by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1251
|
||||
* fix - Can't assign dhcp IP to the migrated instance by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1234
|
||||
* Fix migration timeout for multi-attach RDM volumes by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1247
|
||||
* add setting to delete port after migration failure by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1255
|
||||
* reflect current default migration method in migration form by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1257
|
||||
* Fix batch script to properly write self-delete logic to the generated startup script by @Track2k in https://github.com/platform9/vjailbreak/pull/1213
|
||||
* add UI option to automatically run script to fix fstab entries during migration by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1258
|
||||
* feat: add a net pacakge with unit test cases by @sharma-tapas in https://github.com/platform9/vjailbreak/pull/1160
|
||||
* Added script to check disks status in Windows post-migration by @amar-chand in https://github.com/platform9/vjailbreak/pull/1167
|
||||
* fix agents tenant and security groups by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1260
|
||||
* fix multiple migration succeeded events in amplitude by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1262
|
||||
* fix - Migration fails when port already exist on pcd side (DHCP=true) by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1279
|
||||
* Setting up the default password for the agent nodes by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1281
|
||||
* Fixed default migration-method to cold and map with global settings by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1284
|
||||
* Updating CRDs for release by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1285
|
||||
* Populate metadata in extra specs in openstack creds by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1286
|
||||
|
||||
### New Contributors
|
||||
* @Track2k made their first contribution in https://github.com/platform9/vjailbreak/pull/1213
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.3.6...v0.3.7
|
||||
## v0.3.8
|
||||
|
||||
### What's Changed
|
||||
* Implement Session Timeout (18 hours inactivity) for UI by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1264
|
||||
* install vjbctl binary system wide by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1269
|
||||
* Make datacenter field as an optional entry in vmware creds form by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1256
|
||||
* #1227, #1224 :: Create a Common Component Library for Consistent UI Across the Application by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1297
|
||||
* support additional machine states, optional set to PXE boot by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1301
|
||||
* fix - Agent Node not prompting to change password by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1310
|
||||
* fix errored agent nodes deletion from PCD by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1303
|
||||
* Added script to preserve network interfaces by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1304
|
||||
* #1299 :: New UI – Issues and Required Fixes by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1313
|
||||
* Added advanced option in UI to select if the user wants to persist network interfaces by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1314
|
||||
* add script to check and bring the offline volumes online by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1309
|
||||
* Added a new state to show migrationplan validation failure in ui by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1298
|
||||
* fix - logs for persistance script showing errors by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1317
|
||||
* Add endpoint to take proxy variable, update the cm and restart controller. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1316
|
||||
* Fix logs UI and updated CRDs by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1320
|
||||
* #1294 :: UI add proxy by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1322
|
||||
* #1294 :: UI: Add proxy with separate Http, Https field by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1325
|
||||
* added validationFailed to stop time elapsed by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1328
|
||||
* Refactored network persistance script by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1327
|
||||
* #1331 :: Show warning message on UI after saving proxy by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1332
|
||||
* no_proxy default values by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1335
|
||||
* Fixed migrationplan status based on all edge cases (combination of validationFailed, failed, suceeded, inprogress) by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1333
|
||||
* Fix - Network persistence not working for older versions of ubuntu by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1338
|
||||
* Vmware tools fix by @amar-chand in https://github.com/platform9/vjailbreak/pull/1267
|
||||
* fix - Interfaces with no ip for ubuntu older versions getting default ip by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1340
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.3.7...v0.3.8
|
||||
---
|
||||
title: v0.4.0
|
||||
description: Release Notes for v0.4.0
|
||||
---
|
||||
|
||||
### What's Changed
|
||||
* Added link to public documentation in the ui by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1345
|
||||
* #1336, #834 :: UI implement feedback changes by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1346
|
||||
* Implement Storage SDK Foundation (#1091 #1093) - PART1 by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1291
|
||||
* continues the array-accelerated migration work by implementing the storage array gRPC server layer by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1350
|
||||
* Storage SDK Foundation - Part 3 -- removed all UI changes by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1353
|
||||
* Upload VDDK via UI. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1319
|
||||
* fix: Make VCENTER_DATACENTER optional in secret by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1356
|
||||
* Reverting 3 commits that introduced breaking changes by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1357
|
||||
* storage array integration by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1361
|
||||
* Added migration details modal by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1355
|
||||
* remove stale folders from the project by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1359
|
||||
* Handled trailing slash in vCenter URL by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1349
|
||||
* VDDK upload by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1364
|
||||
* Added more relevant option in MigrationForm by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1347
|
||||
* Bug: Check for empty arraycreds secret ref when normal migration and change names. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1369
|
||||
* Restrict retry on rdm migration by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1365
|
||||
* Added validation for hotplug flavor discovery by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1360
|
||||
* merge two common folders for better code structure by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1379
|
||||
* Added return to avoid segmentation fault or panic by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1387
|
||||
* VM Migrations stats and alerts on grafana dashboards by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1362
|
||||
* #1368, #1367 date time selection is not working for scheduled cutover and copy start time by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1384
|
||||
* feat: adding vddk upload status api by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1377
|
||||
* deterministic volume ordering during copy by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1389
|
||||
* UI: Create UI for storage accelerated copy. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1378
|
||||
* Added missing logs for better debugging by @geet-pf9 in https://github.com/platform9/vjailbreak/pull/1401
|
||||
* feat: adding vddk version in the api by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1397
|
||||
* #731 :: [UI] add prompts for missing VDDK, credentials by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1372
|
||||
* Fix - windows 2022 not able to recognise the network interfaces by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1382
|
||||
* pass vminfo by reference and improve sync error handling by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1391
|
||||
* Reset currentState to initial in case of error and success by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1404
|
||||
* Implemented OpenStack token-based authentication by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1394
|
||||
* feat: adding fuzzy search by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1392
|
||||
* Add VM power status check after poweroff by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1405
|
||||
* Make request limit configurable and increase limit to 5Gib by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1407
|
||||
* feat: Adding netapp storage.go by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1399
|
||||
* Mark migrations ValidationFailed when RDM disk is not managed by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1406
|
||||
* Disabled hour-time-picker for scheduled cutover if minutes are disabled by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1415
|
||||
* Fix issues in vddk upload page by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1418
|
||||
* fix: added buildBackendToVolumeTypeMap function and cleanup logic by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1422
|
||||
* #1424 :: The screen flickers first time when clicking on other Global Settings tabs while the VDDK upload is in progress or uploaded by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1429
|
||||
* #1434 :: Add ESXi SSH Private Key Input Field to Storage Array Credentials Page by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1435
|
||||
* Prioritizing Cold Migration in case of cutover options selected with cold migration by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1439
|
||||
* #1444 :: Couldn't upload ssh key without an extension by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1447
|
||||
* Throttling the go routines during copying changed block stage by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1446
|
||||
* UI :: #1438 :: Admin cutover + cold migration is not a valid usecase by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1441
|
||||
* #1430 :: Updating the vJailbreak settings through the UI removes ConfigMap keys that are not shown in the UI by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1436
|
||||
|
||||
### New Contributors
|
||||
* @geet-pf9 made their first contribution in https://github.com/platform9/vjailbreak/pull/1401
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.3.8...v0.4.0
|
||||
|
||||
---
|
||||
title: v0.4.1
|
||||
description: Release Notes for v0.4.1
|
||||
---
|
||||
|
||||
### What's Changed
|
||||
* upgarde core components by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1458
|
||||
* Network Persistence For Windows by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1408
|
||||
* increase QPS for kubernetes client in proxy pod by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1460
|
||||
* Fixed - v2v build failure by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1471
|
||||
* Added s3 URL artifact to build outputs (release) by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1464
|
||||
* Push image on S3 only for release, nightly and manual triggers by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1474
|
||||
* Added option to migrate a vm without powering off the source vm by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1472
|
||||
* Fixed the variable issue in v2v helper by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1476
|
||||
* Added downloadable s3 url for qcow2 images by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1475
|
||||
* #1451 :: Remove data copy method and cutover options from adavance options when user selects storage accelerated copy by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1473
|
||||
* Install latest golang and libnbd-devel in Dockerfile by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1485
|
||||
* chore: upgrade grafana by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1483
|
||||
* user experience enhancements (download logs) by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1486
|
||||
* add pre-commit hooks for lint and YAML generator by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1494
|
||||
* Use GitHub repository variables for S3 bucket names and region in CI workflow by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1488
|
||||
* Added manual pre-release workflow for CRD and installer generation by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1489
|
||||
* add backoff for migration pod checking logs by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1396
|
||||
* #1454 :: Deselecting the advanced option does not reset the UI to its original state by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1477
|
||||
* Replace pre-baked Ubuntu base image with Ubuntu Minimal and automate K3s/Helm installation by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1496
|
||||
* firstboot scheduling windows by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1500
|
||||
* Run upgrade process as a job by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1467
|
||||
* Removed extra logging by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1490
|
||||
* pin golang lint version by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1517
|
||||
* fix: continue network discovery even for orphaned networks by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1457
|
||||
* #1515 :: UI Bug: “Start Conversion” Button Not Enabled in Rolling Cluster Conversion Form by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1516
|
||||
* #1398 :: Reorganize Main Menu into Two-Level Structure by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1512
|
||||
* replace grafana yamls by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1521
|
||||
* add more printcolumns by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1522
|
||||
* Apply PostMigrationAction for all migrations in a batch by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1492
|
||||
* Support duplicate VM names by using vCenter MOID as a unique identifier by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1523
|
||||
* fix nginx grafana by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1526
|
||||
* Keep icons consistent in all the pages by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1530
|
||||
* #1450 :: UI is not allowing to delete auto discovered storage mapping by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1470
|
||||
* Revert #1523: Remove duplicate vm name changes by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1535
|
||||
* Add ssh validate CR for key validation by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1505
|
||||
* Removed extra logs showing repeated 0% by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1536
|
||||
* Add necessary tools for easier debug ability by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1538
|
||||
* Cluster Conversion: fix the capacity check for esxi hosts by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1504
|
||||
* #1506 :: Create New Page for ESXi SSH Key Management by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1539
|
||||
* fix - Firstboot script for nic recovery is not running and errors on specific windows versions by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1534
|
||||
* add esxi details by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1525
|
||||
* Resolve UI synchronization lag during Admin Cutover by refining MigrationPlan predicates by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1542
|
||||
* Introduce warning error states during periodic sync so that customer can take necessary steps by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1497
|
||||
* Feature/option not to preserve ip and mac by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1511
|
||||
* Fixed retry mechanism by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1544
|
||||
* backend volume type validations by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1498
|
||||
* fix: scope VM validation to non-terminal states and harden post-migration actions by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1549
|
||||
* Create esxi ssh cr while configuring esxi ssh key. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1558
|
||||
* bake virtio 0.1.185 for windows server 2012 by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1425
|
||||
* script to remove log files regarding vmwaretools,vmware etc by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1547
|
||||
* Added advanced option to run vmware removal script with just a check in the migration form by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1550
|
||||
* user firstboot fix by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1569
|
||||
* #1545 : UI - Redirect to the first sub item upon clicking the Item in the sidebar by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1570
|
||||
* fix: adding a timestamp measure to ensure the latest version is fetched for vddk version by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1562
|
||||
* skip deletion of vmwaremachine that was migrated and renamed by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1566
|
||||
* fix generate-mount-persistence invocation for multi-disk by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1564
|
||||
* Remove irrelevent filters on ESXi SSH Credentials page by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1567
|
||||
* #1510 :: UI Request option to NOT preserve the IP address and MAC address to allow migration to a different subnet by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1557
|
||||
* #1443 : Add Storage accelerated copy related information in migration details for storage mapping (currently showing NA) by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1571
|
||||
* UI: Fix rdm configure tab in migration form by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1576
|
||||
* #1574: Update Tour Popup Messaging for Separate VMware and PCD Pages by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1579
|
||||
* fix: on empty IP create only port group else route the standard way by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1573
|
||||
* fix: Migration phase skips CopyingChangedBlocks/ConvertingDisk after admin cutover by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1585
|
||||
* guestfish run fix, fix grub bootloader by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1586
|
||||
* Net persist patch by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1589
|
||||
* Remove 2 errors on UI for rdm form and add a warning dialog box if wrong selected by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1590
|
||||
* Injected Disk-Online script into the codebase and enhanced tool removal script for win2012 by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1578
|
||||
* fix: custom IP is not applied for no preserve IP and no preserve MAC by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1597
|
||||
* #1583 : Cannot remove assign IP post a new IP is applied by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1592
|
||||
* Include resourceVersion when updating ESXi SSH credentials by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1605
|
||||
* fix: adding dhcp search for no ip by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1481
|
||||
* Revert fix generate-mount-persistence invocation for multi-disk by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1606
|
||||
* Continue after failure Firstboot Schduling for windows firstboot by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1604
|
||||
* Interface Name preservation by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1609
|
||||
* Disable github hook on pre-release commit by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1613
|
||||
* chore: Pre-release CRD generation for v0.4.1 by @github-actions[bot] in https://github.com/platform9/vjailbreak/pull/1614
|
||||
* Use Cloud image instead of minimal ubuntu by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1618
|
||||
* Update nginx ingress and prometheus alert manager images ( release ) by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1619
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.4.0...v0.4.1
|
||||
|
||||
|
||||
#### Upgrade Guide: v0.4.0 → v0.4.1
|
||||
|
||||
Users upgrading from v0.4.0 to v0.4.1 need to follow the steps below:
|
||||
|
||||
##### Step 1: Update v0.4.0 Container Images
|
||||
|
||||
In your existing v0.4.0 setup, update the deployment images to pull the latest v0.4.0 containers and set `imagePullPolicy` to `Always` using the following command:
|
||||
|
||||
```bash
|
||||
kubectl patch deployment migration-controller-manager -n migration-system --type='json' \
|
||||
-p='[{"op":"replace","path":"/spec/template/spec/containers/0/imagePullPolicy","value":"Always"}]' && \
|
||||
kubectl patch deployment migration-vpwned-sdk -n migration-system --type='json' \
|
||||
-p='[{"op":"replace","path":"/spec/template/spec/containers/0/imagePullPolicy","value":"Always"}]' && \
|
||||
kubectl patch deployment vjailbreak-ui -n migration-system --type='json' \
|
||||
-p='[{"op":"replace","path":"/spec/template/spec/containers/0/imagePullPolicy","value":"Always"}]'
|
||||
```
|
||||
|
||||
##### Step 2: Restart Deployments
|
||||
|
||||
Restart the deployments to ensure the updated images are pulled and running:
|
||||
|
||||
```bash
|
||||
kubectl rollout restart deployment -n migration-system
|
||||
```
|
||||
|
||||
##### Step 3: Follow Upgrade Steps from the [public documentation](https://platform9.github.io/vjailbreak/guides/how-to/upgrade_vjailbreak/)
|
||||
## v0.4.2
|
||||
|
||||
### What's Changed
|
||||
* UI access control by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1629
|
||||
* refactor for a cleaner code: consolidate go modules and constants by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1560
|
||||
* Simplify S3 QCOW2 upload paths by removing date folders by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1631
|
||||
* fix - Static network interface name is not getting preserved for Rocky9 by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1634
|
||||
* Refactor: move commonly used functions to common package by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1633
|
||||
* fix: Wait for network IP and default route before installing K3s master and worker by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1644
|
||||
* metadata as input by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1639
|
||||
* Implement independent post-migration script execution for mixed OS plans by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1638
|
||||
* #1607 : Cancel button is not working during vddk upload by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1635
|
||||
* #1575, #1577 : Start Migration is not getting disabled by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1637
|
||||
* Added checks for failure in user management vjbctl by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1659
|
||||
* Add exponential backoff auto-reconnect for migration pod log streams by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1657
|
||||
* Fix UI RBAC permissions for pod operations by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1661
|
||||
* fix: Scale up agents on L2 network by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1654
|
||||
* Detect if target is L2 network if so ignore ip by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1666
|
||||
* Added failure checks in vjbctl by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1672
|
||||
* create seperate CI to create base image, use this base image to generate qcow2 by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1677
|
||||
* Revert "create seperate CI to create base image, use this base image to generate qcow2" by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1684
|
||||
* #1543 : VM selection filter is not working properly by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1682
|
||||
* fix: Version lock ingress version by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1686
|
||||
* fix - Migrations failing with - failed to reserve ports for VM by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1688
|
||||
* #1694 : Extract only first IPv4 address when displaying and editing VM IP addresses by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1695
|
||||
* Fix: VJailbreakNode CR status was stuck at "CreatingVM" for L2 networks even after the VM joined the K8s cluster. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1693
|
||||
* Ability to reuse ports in case of l2 network by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1700
|
||||
* #1692 : Support multiple IP addresses per network interface by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1697
|
||||
* API change: multiple ips for single nic in vmwaremachines by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1696
|
||||
* Disabled Fallbacktodhcp and Securitygrp for L2 by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1705
|
||||
* #1694 : Preserve IP for a powered on VM is getting wrong IPs for no IP interfaces by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1704
|
||||
* fix agents migration for L3 by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1706
|
||||
* #1710 : Remove no ip validation in assign IP box for no ip interfaces by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1712
|
||||
* Mount persist debug log by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1711
|
||||
* Disabled assigned ip box for multiple ips by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1713
|
||||
* Defining refresh ui function for vjbctl by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1715
|
||||
* chore: Pre-release CRD generation for v0.4.2 by @github-actions[bot] in https://github.com/platform9/vjailbreak/pull/1716
|
||||
* Added a check to preserve ip by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1718
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.4.1...v0.4.2
|
||||
## v0.4.3
|
||||
|
||||
### What's Changed
|
||||
* fix for no cluster filter by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1726
|
||||
* fix - Unable to migrate powered-off VM without IP address by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1732
|
||||
* Optimise VMware tool removal by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1675
|
||||
* Added dnsConfig with ndots: 1 for controller,v2v-helper and vpwned pods by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1736
|
||||
* Replaced the manual name construction with a call to resolvecinderVolumeToLun Function by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1738
|
||||
* Added delete permissions for secrets by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1740
|
||||
* uuid for image id discovery call by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1739
|
||||
* Duplicate ESXi hosts are visible for multiple VMware credentials by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1707
|
||||
* Preserved non-ASCII chars in Kubernetes secrets by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1745
|
||||
* #1656: Reset to Default button toggles off Auto Fstab Update and sets migration type to hot by default by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1734
|
||||
* #1733 : Add a toggle to pass the instance ID when creating PCD credentials on a VJB VM that was created using an L2 network by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1744
|
||||
* #1648 : Remove the N/A drop down from Storage Accelerated Copy by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1748
|
||||
* Disable security group selection for L2-enabled PCD credentials by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1757
|
||||
* Updating virt-v2v version by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1763
|
||||
* Give permission to UI user to create arraycredsmapping by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1760
|
||||
* mount point for lvm by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1599
|
||||
* Implement subnet compatibility warnings for VM network mapping by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1755
|
||||
* Agents markdown file by @roopakparikh in https://github.com/platform9/vjailbreak/pull/1507
|
||||
* Feat/support virtual portgroups by @sanya-pf9 in https://github.com/platform9/vjailbreak/pull/1730
|
||||
* v2v checks for windows by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1775
|
||||
* Add update patch list to secret for ui role by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1777
|
||||
* #1591 : Migration details in the details modal becomes NA if we remove creds and create new creds, Its reconciling with old creds by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1753
|
||||
* adding proper filtering for agent nodes by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1778
|
||||
* Added devcon utility by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1790
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.4.2...v0.4.3
|
||||
|
||||
### Release Notes & Known Issues
|
||||
* Static IP and interface name preservation is not supported when the target network has DHCP disabled.
|
||||
* For Windows VMs, static IP configurations are automatically converted to DHCP. However, the original source IP is retained on the destination VM to maintain network connectivity.
|
||||
* The VMware Tools removal script may leave behind some residual artifacts. Refer to the [documentation](https://platform9.github.io/vjailbreak/guides/troubleshooting/vmware_residual_artifacts/#_top) for more details.
|
||||
* Agent scaling is not supported for vJailbreak VMs operating on L2 networks.
|
||||
## v0.4.4
|
||||
|
||||
### What's Changed
|
||||
* Add offline VMware Tools cleanup and optimize firstboot script for cleaner migrations by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1779
|
||||
* Claude.md and other files for LLM integration by @roopakparikh in https://github.com/platform9/vjailbreak/pull/1690
|
||||
* Add security scan file for vulnerability scans by @hsri-pf9 in https://github.com/platform9/vjailbreak/pull/1039
|
||||
* Removing the volume attachment delay due to metadata service connectivity by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1804
|
||||
* ci: skip build-image and lint workflow by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1807
|
||||
* Support duplicate VM names by using vCenter MOID as a unique identifier by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1772
|
||||
* fix - Interface preservation not working on DHCP disabled network for windows by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1805
|
||||
* #1761 : Bugsnag not working properly by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1765
|
||||
* Fix multi-disk volume-type mismatch by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1815
|
||||
* fix: update VM identification from name to ID in VmsSelectionStep by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1817
|
||||
* validate CURRENT_INSTACE_ID is in the same env by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1816
|
||||
* #1783 : Duplicate Amplitude Events Triggered During Migration by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1791
|
||||
* Added user assigned ip per nic in backend by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1719
|
||||
* Added UI for per-NIC multi-IP overrides by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1820
|
||||
* Added workflow for old builds cleanup from quay and S3 by @geet-pf9 in https://github.com/platform9/vjailbreak/pull/1735
|
||||
* change volume attachment wait time and logs by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1819
|
||||
* Virtio installation in windows by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1824
|
||||
* Improved Mac Filtering by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1831
|
||||
* 1825 : Enhance Amplitude Events with OS Region Name from Credentials by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1835
|
||||
* feat: add UI support for setting volume metadata prior to migration by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1838
|
||||
* feat: add volume image properties prior to migration by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1834
|
||||
* Handling interfaces with no ip for rhel based os by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1842
|
||||
* UI: show selected profiles in details modal by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1841
|
||||
* Remove default profile auto-selection and fix boot volume metadata merge by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1846
|
||||
* Update portgroupkey if stale with correct live mor of the dvpg. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1836
|
||||
* improve bootable partition detection for Grub 2.12 and add script logging by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1829
|
||||
* L2 scaling support. Don't query metadataservice, get uuid from pod's nodename. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1848
|
||||
* Feature: Add FC support for pure and netapp. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1851
|
||||
* fix - Suse-11-4 - VM ends up in maintenance mode post migration by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1850
|
||||
* fix - dirty disk post migration windows by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1856
|
||||
* Pass vmkey instead of vmname to delete object by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1865
|
||||
* Map lun to igroup based on svm by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1866
|
||||
* Prevent the user from adding multiple IPs if the Preserve IP toggle is turned off by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1863
|
||||
* use custom http timeout from settings by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1860
|
||||
* Remove L2 instance ID from UI and backend by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1858
|
||||
* Fixed master instance ID issue by @geet-pf9 in https://github.com/platform9/vjailbreak/pull/1871
|
||||
* After we copy the disks via storagecopy add image tags to boot correctly by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1870
|
||||
* Bug: Use GetIsSimpleNetwork method instead of using stale env variable by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1875
|
||||
* increased version window for github tags by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1876
|
||||
* Keepalive client mechanism by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1881
|
||||
|
||||
### New Contributors
|
||||
* @hsri-pf9 made their first contribution in https://github.com/platform9/vjailbreak/pull/1039
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.4.3...v0.4.4
|
||||
|
||||
### Highlights
|
||||
- **VMware Tools Removal:** The removal script now removes all residual files and folders. A small number of registry entries may remain depending on the Windows version, but these are harmless and can be removed manually if needed.
|
||||
- **Migration Profiles:** Pre-defined key-value pairs can now be applied to a migrated VM's root volume in OpenStack. Profiles are supported for both Windows and Linux guests.
|
||||
- **L2 Network Scaling Support:** Scaling of agents in L2 network (Simple Networking) is now supported.
|
||||
- **Persistent Network Interface for Windows (2016+):** Static network configurations including interface name, IP, MAC, and gateway are now preserved across migration for Windows Server 2016 and above.
|
||||
- **FC Support for Storage Area Migration (SAM):** Fibre Channel support has been added for SAM workflows, verified with NetApp FC targets.
|
||||
|
||||
### Known Limitations
|
||||
- **Windows 2012 and Earlier — Persist Network:** The persistent network interface option is not supported on Windows 2012 and below. IP and MAC addresses are preserved, but the interface name and gateway may get lost, and the NIC configuration becomes dynamic after migration.
|
||||
- **Migration Profiles — Upgrade Path:** The two default profiles (Windows and Linux) are auto-created on fresh installations only. Users upgrading from lower versions to v0.4.4 will need to create these profiles manually.
|
||||
- **VMware Tools Registry Entries:** Depending on the Windows version, a small number of VMware Tools registry entries (listed in public docs) may not be removed by the uninstall script. These are harmless but can be removed manually if desired.
|
||||
- **FC SAM — Verified Target:** FC support for SAM has been verified against NetApp FC targets. Compatibility with other FC storage vendors is not yet validated.
|
||||
## v0.4.5
|
||||
|
||||
### What's Changed
|
||||
* Fix RDM configuration issue from UI by @geet-pf9 in https://github.com/platform9/vjailbreak/pull/1895
|
||||
* Bug: Fix unauthenticated error when doing vcenter operations after a long time. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1891
|
||||
* Fixed migration issue for shared rdm disk by @geet-pf9 in https://github.com/platform9/vjailbreak/pull/1902
|
||||
* chore: Pre-release CRD generation for v0.4.5 by @github-actions[bot] in https://github.com/platform9/vjailbreak/pull/1904
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.4.4...v0.4.5
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: Cluster Conversion
|
||||
description: Overview of Cluster Conversion Process
|
||||
---
|
||||
|
||||
vJailbreak offers two primary migration options
|
||||
|
||||
## VM Migration
|
||||
The default option, where a user selects a set of VMs within VMware, across clusters and migrates them. This keeps
|
||||
the source VM intact and creates a new copy of them into OpenStack/PCD.
|
||||
|
||||
## Cluster Conversion
|
||||
The second option, where a user selects a cluster within VMware and migrates it to a PCD cluster. This converts not only the VMs within the cluster but also the individual ESXi into PCD Hypervisor.
|
||||
This is done through 'evacuating' the ESXi host and converting it into PCD hypervisor through IPMI/PXE, in the current version of vJailbreak, Canonical MAAS is used to achieve that.
|
||||
|
||||
See below the animation of the cluster conversion process.
|
||||
|
||||
|
||||
|
||||
Choose a VMware cluster and select the destination cluster in PCD. Once the clusters are selected, you will be shown the VMware ESXi hosts and the corresponding VMs. The VM portion of the wizard is similar/same as that in the [VM Migration](#vm-migration) section.
|
||||
|
||||
The ESXi portion of the wizard is different from the VM portion and deals with options on how each server will be configured as a hypervisor in the PCD cluster. The most important aspect is the Host configuration, the information is pulled from the PCD cluster blueprint. The host config determines what NICs are associated with what networks. See [PCD cluster blueprint docs](https://platform9.com/docs/private-cloud-director/private-cloud-director/virtualized-cluster-blueprint) for more details.
|
||||
|
||||
The process of converting the ESXi into PCD hypervisor is simple, each ESXi host is put into maintenance mode which migrates all the running VMs into other ESXi hosts. Then the ESXi host is converted into PCD hypervisor and the VMs are migrated into the PCD hypervisor. This process is repeated for all the ESXi hosts in the cluster.
|
||||
|
||||
The detailed configuration steps are described in [cluster conversion guide](../../guides/cluster-conversion/cluster-conversion/).
|
||||
|
||||
See below the diagram of the cluster conversion setup.
|
||||
|
||||
|
||||
|
||||
|
||||
:::note
|
||||
The conversion of ESXi into PCD hypervisor is a one time operation and cannot be undone. All the VMs are converted into PCD VMs and requires a fully DRS cluster configuration on the VMware side.
|
||||
:::
|
||||
@@ -0,0 +1,174 @@
|
||||
---
|
||||
title: Credential Management
|
||||
description: Overview of Credential Management
|
||||
---
|
||||
|
||||
Before you start using vJailbreak, you need to provide credentials for both the VMware vCenter and OpenStack/PCD environments.
|
||||
|
||||
## VMware vCenter Credentials
|
||||
VMware vCenter credentials are required to connect to the vCenter server and retrieve information about the virtual machines you want to migrate.
|
||||
|
||||
The credentials should have enough permissions to retrieve information about the virtual machines you want to migrate and if you are looking to the cluster conversion, the credentials should have enough permissions to retrieve information about the cluster, put host into maintenance mode, etc (see [Cluster Conversion](../../guides/cluster-conversion/) for more details).
|
||||
|
||||
The VMware credentials needs vCenter Server IP address or vCenter Server name, username and password.
|
||||
The credentials also take the Datacenter name and the VMs, Hosts being worked on would be restricted to the Datacenter specified in the credentials.
|
||||
|
||||
Some VMware environments may be using self signed certificates, in such cases, you would need to "Allow insecure connection" option in the credentials.
|
||||
|
||||
|
||||
## OpenStack/PCD Credentials
|
||||
OpenStack/PCD credentials are required to create VMs inside the OpenStack/PCD environment. The credentials are supplied via the `openstack.rc` file that is available in the PCD environment.
|
||||
|
||||
To copy the content of the `openstack.rc` file, you should navigate to Settings > API Access > pcdctl RC section.
|
||||
|
||||
If using PCD we recommend toggling the "Is PCD credentials" option. This will automatically indicate to vJailbreak that the credentials are for PCD and would use PCD Cluster as a destination for different migrations.
|
||||
|
||||
For non PCD environment the `openstack.rc` file will be available as part of various distribution and documentation. The `openstack.rc` file is typically used for any automation with the OpenStack CLI.
|
||||
|
||||
---
|
||||
|
||||
### Password-Based Authentication
|
||||
|
||||
#### Required Variables
|
||||
|
||||
vJailbreak requires the following environment variables to be present in your admin RC file. **All of these variables are mandatory** and the migration will fail if any are missing:
|
||||
|
||||
| Variable | Description | Example |
|
||||
|----------|-------------|---------|
|
||||
| `OS_AUTH_URL` | OpenStack Keystone authentication URL | `https://keystone.example.com:5000/v3` |
|
||||
| `OS_USERNAME` | OpenStack username with admin privileges | `admin` |
|
||||
| `OS_PASSWORD` | Password for the OpenStack user | `your-secure-password` |
|
||||
| `OS_REGION_NAME` | OpenStack region where VMs will be created | `RegionOne` |
|
||||
| `OS_PROJECT_NAME` | OpenStack project name for VM deployment | `service` |
|
||||
| `OS_PROJECT_DOMAIN_NAME` | OpenStack project domain name | `Default` |
|
||||
| `OS_AUTH_TYPE` | OpenStack authentication type | `password` |
|
||||
| `OS_IDENTITY_API_VERSION` | OpenStack identity API version | `3` |
|
||||
| `OS_USER_DOMAIN_NAME` | OpenStack user domain name | `Default` |
|
||||
| `OS_INTERFACE` | OpenStack API interface type | `public` |
|
||||
|
||||
#### Optional Variables
|
||||
|
||||
| Variable | Description | Example |
|
||||
|----------|-------------|---------|
|
||||
| `OS_INSECURE` | Skip SSL certificate verification | `true` or `false` |
|
||||
|
||||
#### User Permissions
|
||||
|
||||
The user specified in `OS_USERNAME` must have administrative privileges in OpenStack to:
|
||||
- Create and manage virtual machines
|
||||
- Access network and storage resources
|
||||
- Create and manage volumes
|
||||
- Access compute, network, and storage services
|
||||
|
||||
The project specified in `OS_PROJECT_NAME` must exist and have sufficient quotas for the VMs being migrated.
|
||||
|
||||
#### Example Admin RC File (Password-Based)
|
||||
|
||||
```bash
|
||||
export OS_USERNAME=<your-username>
|
||||
export OS_PASSWORD=<your-password>
|
||||
export OS_AUTH_URL=https://<fqdn of the openstack/pcd>/keystone/v3
|
||||
export OS_AUTH_TYPE=password
|
||||
export OS_IDENTITY_API_VERSION=3
|
||||
export OS_REGION_NAME=region-1
|
||||
export OS_USER_DOMAIN_NAME=Default
|
||||
export OS_PROJECT_DOMAIN_NAME=Default
|
||||
export OS_PROJECT_NAME=service
|
||||
export OS_INTERFACE=public
|
||||
export OS_INSECURE=false
|
||||
````
|
||||
|
||||
---
|
||||
|
||||
### Token-Based Authentication
|
||||
|
||||
In addition to password-based authentication, vJailbreak also supports **token-based authentication** for OpenStack/PCD environments.
|
||||
|
||||
With token-based authentication, access is provided using a **Keystone authentication token** instead of a username and password. The token must be generated in your OpenStack environment and supplied to vJailbreak via the `openstack.rc` file.
|
||||
|
||||
This authentication method is useful in environments where password-based authentication is restricted or where short-lived credentials are preferred.
|
||||
|
||||
#### Required Variables
|
||||
|
||||
When using token-based authentication, the following environment variables **must** be present in the RC file:
|
||||
|
||||
| Variable | Description | Example |
|
||||
| ------------------------- | -------------------------------------------- | ------- |
|
||||
| `OS_AUTH_URL` | OpenStack Keystone authentication URL | `https://keystone.example.com:5000/v3` |
|
||||
| `OS_IDENTITY_API_VERSION` | OpenStack identity API version. | `3` |
|
||||
| `OS_REGION_NAME` | OpenStack region where VMs will be created | `RegionOne` |
|
||||
| `OS_PROJECT_NAME` | OpenStack project name for VM deployment | `service` |
|
||||
| `OS_PROJECT_DOMAIN_NAME` | OpenStack project domain name | `Default` |
|
||||
| `OS_INTERFACE` | OpenStack API interface type | `public` |
|
||||
| `OS_AUTH_TOKEN` | Openstack authentication token | `<keystone-auth-token>` |
|
||||
| `OS_AUTH_TYPE` | Openstack authentication type | `token` |
|
||||
|
||||
#### Optional Variables
|
||||
|
||||
| Variable | Description | Example |
|
||||
|----------|-------------|---------|
|
||||
| `OS_INSECURE` | Skip SSL certificate verification | `true` or `false` |
|
||||
|
||||
#### Example Admin RC File (Token-Based)
|
||||
|
||||
```bash
|
||||
export OS_AUTH_URL=https://<fqdn of the openstack/pcd>/keystone/v3
|
||||
export OS_IDENTITY_API_VERSION=3
|
||||
export OS_REGION_NAME=<region-name>
|
||||
export OS_PROJECT_NAME=<project-name>
|
||||
export OS_PROJECT_DOMAIN_NAME=Default
|
||||
export OS_INTERFACE=public
|
||||
export OS_AUTH_TOKEN=<keystone-auth-token>
|
||||
export OS_AUTH_TYPE=token
|
||||
```
|
||||
|
||||
#### Notes on Token-Based Authentication
|
||||
|
||||
* The `OS_AUTH_TOKEN` must be generated in your OpenStack environment and must be valid at the time of migration.
|
||||
* Token expiration is controlled by Keystone. If the token expires, the migration will fail and a new token must be provided.
|
||||
* The `openstack.rc` must contain both the `Domain` and the `Project`/`Tenant` information. When using the OpenStack credentials, the `Domain` and `Project`/`Tenant` information is used as the destination `domain` and `project`/`tenant` for the OpenStack/PCD environment.
|
||||
|
||||
### Credential Revalidation
|
||||
|
||||
Revalidation re-runs the same flow that runs on credential creation. It is triggered automatically by the controller and can also be initiated manually from the UI.
|
||||
|
||||
|
||||
|
||||
|
||||
#### What Revalidation Does
|
||||
|
||||
When a credential is revalidated, vJailbreak performs two steps:
|
||||
|
||||
1. **Authentication check** — verifies the credentials are still valid against the target environment (vCenter for VMware, Keystone for OpenStack/PCD). If authentication fails, the credential is marked invalid and migrations using it will be blocked.
|
||||
2. **Resource resync** — if authentication succeeds, vJailbreak re-fetches the full inventory of resources tied to that credential.
|
||||
|
||||
**For VMware credentials**, revalidation refreshes:
|
||||
- Virtual Machines (CPU, memory, disks, networks, datastores, power state, guest IPs)
|
||||
- vCenter clusters and ESXi hosts
|
||||
- Stale VMs, clusters, and hosts removed from the source are also pruned from vJailbreak
|
||||
|
||||
**For OpenStack/PCD credentials**, revalidation refreshes:
|
||||
- Compute flavors
|
||||
- Networks
|
||||
- Volume types
|
||||
- For PCD credentials: PCD clusters, hosts, and host configs
|
||||
|
||||
#### When Revalidation Runs
|
||||
|
||||
- **On credential creation** — initial validation + resource fetch.
|
||||
- **Periodically** — the controller reconciles every 1 hour by default to keep resources in sync. Default time to requeue creds can be changed in global setting page.
|
||||
- **Manually** — click the refresh button on the Credentials page to trigger an immediate revalidation.
|
||||
|
||||
|
||||
#### Important: VMware IP Discovery and Credential Revalidation
|
||||
|
||||
VMware Tools and guest IP addresses can take some time to appear in vCenter after powering on a VM or making network changes.
|
||||
|
||||
**Best Practice:**
|
||||
- Make all necessary configuration changes to your VMs in the vCenter UI first.
|
||||
- **Wait** until the IP addresses are clearly visible on the VM summary page in vCenter.
|
||||
- Only then click **Add Credential** or **Revalidate** in vJailbreak.
|
||||
|
||||
Revalidating too early may result in missing IP information, which can prevent proper IP preservation on the destination and cause migration issues.
|
||||
|
||||
> **Note**: vJailbreak will show a warning for VMs where network interfaces are detected but IPs could not be discovered.
|
||||
@@ -0,0 +1,112 @@
|
||||
---
|
||||
title: Migration Options
|
||||
description: Overview of Different Migration Options
|
||||
---
|
||||
|
||||
vJailbreak provides a number of options to optimize and control the migration process. These options are available in the migration wizard under "Migration Options".
|
||||
|
||||
## Copy options
|
||||
There are several options available to control how data is copied during migration.
|
||||
|
||||
### Data copy method
|
||||
Determines how the data copy is done
|
||||
|
||||
* **Copy live VMs, then power off** - This option copies the data from the live VMs to the OpenStack/PCD volumes. vJailbreak uses CBT (Change Block Tracking) to copy the data that is dirtied. Then, the VMs are powered off and the remaining changed blocks are copied to the OpenStack/PCD volumes (see cut over options below)
|
||||
|
||||
* **Power off VMs, then copy** - This option powers off the VMs and then copies the data to the OpenStack/PCD volumes. There is no CBT involved in this case, it will be the faster option, but will impact the uptime of the application. Power off VMs are supported but may need user input to provide the IP address, Operating System type during migration.
|
||||
|
||||
### Storage copy method
|
||||
Determines the underlying mechanism used to transfer disk data.
|
||||
|
||||
* **Normal** - Uses the traditional network-based copy via VMware's NFC protocol. Data is transferred from ESXi hosts to OpenStack Cinder volumes over the network. This method is limited to approximately 1 Gbps per VMDK due to NFC protocol constraints. **Requires VDDK.**
|
||||
|
||||
* **Storage-Accelerated Copy** - Leverages storage array-level XCOPY operations for dramatically faster migrations. Instead of copying data over the network, this method offloads the copy to the storage array itself. **Does not require VDDK.** Requires:
|
||||
- Supported storage array (Pure Storage or NetApp)
|
||||
- Both VMware datastores and OpenStack Cinder backed by the same array
|
||||
- ESXi SSH access configured
|
||||
- VMs must be powered off during copy (cold migration only)
|
||||
|
||||
* **vJailbreak Accelerated Copy** *(default)* - Attaches frozen snapshot disks directly to a Proxy VM running in vCenter (using VMware's hot-add mechanism) and streams data over NBD to the destination. Works with any datastore type (NFS, VMFS, vSAN) and does not require a shared storage array. **Does not require VDDK.** Requires:
|
||||
- A registered Proxy VM in **Ready** state (Linux VM with `qemu-nbd` installed)
|
||||
- SSH access from vJailbreak to the Proxy VM
|
||||
- VMs must be powered off during copy (**cold migration only; hot/live copy is not supported**)
|
||||
|
||||
:::caution[vJailbreak Accelerated Copy: cold migration only]
|
||||
vJailbreak Accelerated Copy powers off the source VM before attaching its disks. It **cannot** be
|
||||
used with the **"Copy live VMs, then power off"** data copy method. Select **"Power off VMs, then
|
||||
copy"** when using this storage copy method.
|
||||
:::
|
||||
|
||||
:::tip[Running without VDDK?]
|
||||
If VMware's public VDDK download pages are unavailable, use **vJailbreak Accelerated Copy** or
|
||||
**Storage-Accelerated Copy**; neither method requires VDDK. **Normal (Standard) copy** is the
|
||||
only method that requires VDDK.
|
||||
:::
|
||||
|
||||
:::tip
|
||||
Storage-Accelerated Copy can be 10-100x faster than normal copy for large VMs. For a 1 TB disk, normal copy takes ~2.5 hours while Storage-Accelerated Copy can complete in 5-30 minutes.
|
||||
:::
|
||||
|
||||
See [vJailbreak Accelerated Copy](../vjailbreak-accelerated-copy/) for configuration instructions.
|
||||
|
||||
See [Storage-Accelerated Copy](../storage-accelerated-copy/) for detailed configuration instructions.
|
||||
|
||||
### Data copy start time
|
||||
As the name implies, determines when the copy operation should start, typically used to start the migration during off-peak hours.
|
||||
|
||||
## Cutover options
|
||||
There are 3 options available
|
||||
|
||||
* **Cutover during time window** - This option allows the user to specify a time window during which the VM would be powered off and the corresponding OpenStack/PCD VM would be configured and powered on. This window also involves copy of any remaining changed blocks to the OpenStack/PCD volumes since the last time the block were copied.
|
||||
|
||||
* **Cutover immediately after data copy** - This option is simpler and follows the copy operation immediately after the copy is complete. This option is recommended for applications that have flexible uptime requirements and can be powered off anytime during the migration.
|
||||
|
||||
* **Admin initiated cutover** - This option allows the user to manually trigger the cutover operation after the data copy is complete.
|
||||
|
||||
## Data Copy Method Workflows
|
||||
|
||||
### 1. Power off Live VM, then Copy
|
||||
|
||||
#### Immediately Cutover
|
||||
The VM is powered off on the source before the initial copy begins. Once the initial copy completes, the migration immediately performs the final sync and powers on the VM at the destination.
|
||||
|
||||
#### Cutover During Time Window
|
||||
The VM is powered off on the source before the initial copy begins. After the initial copy completes, the migration waits for the specified time window. When the time window arrives, it performs the final sync and powers on the VM at the destination.
|
||||
|
||||
#### Admin Initiated Cutover
|
||||
The VM is powered off on the source before the initial copy begins. After the initial copy completes, the migration waits for manual intervention. When the admin initiates cutover, the migration performs the final sync and powers on the VM at the destination.
|
||||
|
||||
> **Note:** When "Power off VMs then copy" is selected, cutover timing options (immediate, time window, or admin-initiated) are disabled in the UI.
|
||||
|
||||
### 2. Copy Live VM, then Power off
|
||||
|
||||
#### Immediately Cutover
|
||||
The initial copy is performed while the VM remains running on the source. Once the initial copy completes, the VM is powered off on the source, and the migration immediately performs the final sync and powers on the VM at the destination.
|
||||
|
||||
#### Cutover During Time Window
|
||||
The initial copy is performed while the VM remains running on the source. After the initial copy completes, the migration waits for the specified time window. When the time window arrives, the VM is powered off on the source, the final sync is performed, and the VM is powered on at the destination.
|
||||
|
||||
#### Admin Initiated Cutover
|
||||
The initial copy is performed while the VM remains running on the source. After the initial copy completes, the migration waits for manual intervention. When the admin initiates cutover, the VM is powered off on the source, the final sync is performed, and the VM is powered on at the destination.
|
||||
|
||||
## Post migration options
|
||||
|
||||
### Post migration script
|
||||
A script to be executed after the migration is complete. This script is optional and can be used to perform post migration tasks such as starting the application, updating the application configuration, adding VM to domain controller etc.
|
||||
|
||||
### Rename VM
|
||||
An optional parameter. Renames the source VM in VMware to have a specific suffix, good option to indicate a VM is migrated to OpenStack/PCD. The default suffix is "_migrated_to_pcd".
|
||||
|
||||
### Move to folder
|
||||
An optional parameter. Moves the source VM in VMware to a specific folder, good option to group migrated VMs and keep it out of the hands of the user.
|
||||
## Network persistence
|
||||
|
||||
### Persist source network interfaces
|
||||
When enabled, vJailbreak preserves the source VM's network interface names on the destination VM (for example, `eth0` or `ens3`). This prevents breaking guest configurations—such as firewall rules or legacy scripts—that depend on specific interface names.
|
||||
|
||||
For statically configured interfaces, vJailbreak also preserves routes defined in configuration files, ensuring the guest retains its original network behavior after migration.
|
||||
|
||||
To enable this behavior, check **Persist source network interfaces** under **Migration Options** in the migration form.
|
||||
|
||||
|
||||
For more information, refer to the [Network Persistence](../network-persistence/) documentation.
|
||||
@@ -0,0 +1,100 @@
|
||||
---
|
||||
title: Network Persistence
|
||||
description: Guide to Linux and Windows network interface persistence post-migration
|
||||
---
|
||||
|
||||
# Network Persistence Post-Migration
|
||||
|
||||
This document details the mechanism for ensuring network interface persistence following a virtual machine migration for both Linux and Windows operating systems.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Network persistence is only applied when the **"Persist source network interfaces"** option is enabled in the migration form. This option must be selected during migration configuration to ensure that network interface names are preserved on the destination VM.
|
||||
|
||||
## Linux Network Persistence
|
||||
|
||||
The Linux network persistence mechanism operates on the first boot post-migration to restore network configuration to its pre-migration state.
|
||||
|
||||
### Persistence Mechanism
|
||||
|
||||
- **Statically Configured Interfaces**: The original names of network interfaces that were statically configured before migration are preserved.
|
||||
- **DHCP Configured Interfaces**: Interfaces configured via DHCP may be renamed to a consistent pattern: `vjb<random_number>`.
|
||||
- **Interface with No Configuration**: Interfaces that had no configuration (e.g., were left unconfigured) will remain untouched but the name may change.
|
||||
|
||||
### Supported Distributions
|
||||
|
||||
| Distribution | Expected | Verified |
|
||||
| --- | --- | --- |
|
||||
| Ubuntu | Supported | Yes |
|
||||
| OpenSuse | Supported | Yes |
|
||||
| RHEL | Supported | Yes |
|
||||
| CentOS | Supported | Yes |
|
||||
| Rocky | Supported | No |
|
||||
|
||||
## Windows Network Persistence
|
||||
|
||||
The Windows network persistence mechanism operates on the first boot post-migration to restore network configuration to its pre-migration state.
|
||||
|
||||
### Persistence Mechanism
|
||||
|
||||
The network persistence script runs on the first boot post-migration. Its primary function is to restore the network configuration to its pre-migration state by performing the following actions:
|
||||
|
||||
- **Windows Server 2016 and Above**:
|
||||
- **Statically Configured Interfaces**: The original interface name, IP address, and gateway from the source are persisted on the destination, ensuring continuous network connectivity.
|
||||
- **DHCP Configured Interfaces**: Interfaces configured via DHCP are renamed to a consistent pattern: `vjb_<random_number>`.
|
||||
|
||||
- **Windows Server 2012 and below**:
|
||||
- **Statically Configured Interfaces**: The IP address from the source interface is preserved, but the interface configuration is converted to DHCP. The interface name and gateway are not preserved.
|
||||
|
||||
### Supported Versions
|
||||
|
||||
The network persistence mechanism has been validated and is supported on the following Windows Server operating systems:
|
||||
|
||||
| Version | Expected | Verified |
|
||||
| --- | --- | --- |
|
||||
| Windows Server 2016 | Supported | Yes |
|
||||
| Windows Server 2019 | Supported | Yes |
|
||||
| Windows Server 2022 | Supported | Yes |
|
||||
| Windows Server 2025 | Supported | Yes |
|
||||
| Windows Server 2008 | Unsupported | No |
|
||||
| Windows Server 2012 | Unsupported | No |
|
||||
|
||||
:::caution
|
||||
**Unsupported Windows Versions**
|
||||
|
||||
Windows Server 2008 and Windows Server 2012 are **not supported** for network persistence. Post-migration, VMs running these versions will receive IP addresses via DHCP on all interfaces, regardless of the original network configuration.
|
||||
:::
|
||||
|
||||
## User Guidance for Virtio Installation
|
||||
|
||||
The Windows Virtual Machine (VM) will undergo multiple reboots during the installation of necessary virtio drivers post-migration.
|
||||
|
||||
:::caution
|
||||
**Crucial Action**: The user must wait for the virtio installation and subsequent reboots to complete before attempting to log in. Interrupting the installation process by logging in prematurely can lead to an inconsistent network configuration state.
|
||||
:::
|
||||
|
||||
## Important Considerations
|
||||
|
||||
:::caution
|
||||
**Important: Routing Considerations**
|
||||
|
||||
If a VM has multiple interfaces on the same subnet and has asymmetric routing table, the destination openstack platform may not support it and drop the packets. This may cause partial connectivity. This is mainly observed when a VM with asymmetric routing is having port-security enabled.
|
||||
|
||||
**Recommendation:**
|
||||
- To avoid asymmetric routing, ensure each interface is on a unique subnet or consolidate multiple IPs onto a single port, as multiple interfaces on the same subnet will cause connectivity issues.
|
||||
:::
|
||||
|
||||
:::note
|
||||
For DHCP-enabled ports, connectivity and DHCP functionality are preserved, but the interface name may be renamed if this feature is not selected.
|
||||
:::
|
||||
|
||||
:::note
|
||||
For cross-network migration, network persistence is currently not supported and will be blocked.
|
||||
:::
|
||||
|
||||
:::note
|
||||
Network persistence is applied by `virt-v2v` during conversion. Windows VMs whose
|
||||
system volume is on a dynamic disk (LDM) skip conversion, so persistence does not
|
||||
run for them and the interfaces must be reconfigured inside the guest. See
|
||||
[Windows Dynamic Disk (LDM) Migration](../../guides/how-to/windows-ldm-migration/).
|
||||
:::
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: Network & Storage Mapping
|
||||
description: Overview of Network and Storage Mapping
|
||||
---
|
||||
|
||||
A large scale VMWare migration may require a large number of VMs to be migrated. In such cases, it is recommended to use network and storage mapping to optimize the migration process and keep both the environments running at the same time while migration is progressing. Network and Storage mapping are part of the migration wizard and are required for the migration to proceed.
|
||||
|
||||
## Network Mapping
|
||||
|
||||
vJailbreak recognizes the different types of networks in VMware and OpenStack/PCD environments.
|
||||
We recommend to create the OpenStack/PCD networks in advance such that some multi-VM applications can continue to run while the migration is in progress.
|
||||
|
||||
:::note
|
||||
If you enable **Persist source network interfaces**, network persistence may not work for cross network migration and will be blocked in such cases. Read more in [Migration Options](../migration-options/#persist-source-network-interfaces).
|
||||
:::
|
||||
|
||||
### VMware Network Types
|
||||
For VMware environment, the networks are typically of type `vSphere Standard Port Group` or `vSphere Distributed Port Group`. Currently, vJailbreak supports only these two types of networks and not `NSX` created networks.
|
||||
|
||||
Typical VMware networks use VLAn configuration to define the network properties.
|
||||
|
||||
### OpenStack/PCD Network Types
|
||||
For OpenStack/PCD environment, there are many more choices, refer to the PCD and OpenStack documentation on the various provider, physical and virtual networks.
|
||||
|
||||
vJailbreak expects the user to create the OpenStack/PCD networks in advance. In a typical environment for each VMware network an OpenStack/PCD physical network is created that use the corresponding VLAN of the Port Group or Distributed Port Group.
|
||||
|
||||
## Storage Mapping
|
||||
|
||||
Unlike network mapping, storage mapping is different. For networking, interconnectivity is the key, for storage it is not. During migration vJailbreak 'copies' the data over from VMware to OpenStack/PCD and this can be used to your advantage as needed.
|
||||
|
||||
### VMware Storage Types
|
||||
|
||||
For VMware environments, the storage is typically of type `vSphere Datastore` with either `VMFS` or `NFS` as the storage type. vJailbreak supports both of these storage types.
|
||||
|
||||
vJailbreak also supports RDM disks for cold migrations to Platform9 Private Cloud Director (PCD) when the SAN-backed LUN can be represented as a target volume and the required storage prerequisites are met. See the [RDM migration guide](../../guides/cli-api/migrating_rdm_disk_windows_cluster_machine_using_cli/) for the step-by-step workflow. This support is not currently available for OpenStack-targeted migrations.
|
||||
|
||||
There are a few exceptions and unsupported configurations.
|
||||
|
||||
* vJailbreak does not support `vCenter Storage Policies` or `vVols` at the time of writing this document.
|
||||
* vJailbreak does not preserve snapshots during the copy.
|
||||
* For Rolling Conversion or other vMotion-based workflows, RDM disks in physical mode remain unsupported.
|
||||
|
||||
### OpenStack/PCD Volume Types
|
||||
For OpenStack/PCD environment, the volumes are created using 'Cinder' and can be of type `NFS` `iSCSI`, `FiberChannel`. vJailbreak supports all of these types of storage with the help of the corresponding OpenStack/PCD Cinder drivers. The Cinder and corresponding volume types must be precreated before the migration starts.
|
||||
|
||||
Since the migration involves copying the data from VMware to OpenStack/PCD, the storage types can be of different types, for example `NFS` datastore volume can be copied to `iSCSI` volume in OpenStack/PCD.
|
||||
|
||||
## Storage-Accelerated Copy
|
||||
|
||||
For environments where both VMware and OpenStack share the same storage array (Pure Storage or NetApp), vJailbreak supports **Storage-Accelerated Copy**. This method leverages storage array-level XCOPY operations to dramatically improve migration performance by offloading the data copy to the storage array itself.
|
||||
|
||||
Instead of copying data over the network (limited to ~1 Gbps per VMDK), Storage-Accelerated Copy performs the copy directly on the storage array at array speeds, which can be considerably faster than normal copy.
|
||||
|
||||
|
||||
See [Storage-Accelerated Copy](../storage-accelerated-copy/) for detailed configuration and usage instructions.
|
||||
|
||||
:::note
|
||||
Migration involves copying of the data from VMware to PCD, depending on the bandwidth and the network congestion, the migration can take a long time and needs more resources on the vJailbreak VM. See [scaling guide](../../guides/how-to/scaling/) for parallel migrations.
|
||||
:::
|
||||
@@ -0,0 +1,600 @@
|
||||
---
|
||||
title: Storage Accelerated Copy
|
||||
description: High-performance VM migration using storage array level XCOPY operations
|
||||
---
|
||||
|
||||
Storage Accelerated Copy is an advanced data copy method that leverages storage array level XCOPY operations to dramatically improve migration performance. Instead of copying data over the network via the traditional NBD/NFC protocol, this method offloads the data copy to the storage array itself, achieving significantly faster transfer speeds.
|
||||
|
||||
:::note[VDDK not required]
|
||||
Storage-Accelerated Copy does not require VDDK at any stage. Disk data is copied directly by the
|
||||
storage array via `vmkfstools` XCOPY. VDDK is never used. This method is unaffected by VDDK
|
||||
availability.
|
||||
:::
|
||||
|
||||
## Overview
|
||||
|
||||
### How It Works
|
||||
|
||||
Traditional vJailbreak migrations copy VM disk data from VMware ESXi hosts to PCD Cinder volumes over the network using the NFC (Network File Copy) protocol. This approach is limited to approximately **1 Gbps per VMDK** due to VMware's NFC protocol constraints.
|
||||
|
||||
Storage-Accelerated Copy bypasses this limitation by:
|
||||
|
||||
1. Creating a target volume directly on the storage array
|
||||
2. Importing the volume into PCD Cinder
|
||||
3. Mapping the volume to the ESXi host
|
||||
4. Using ESXi's `vmkfstools` to perform an XCOPY clone operation directly on the storage array
|
||||
5. The storage array handles the data copy internally.
|
||||
|
||||
### Benefits
|
||||
|
||||
- **Dramatically faster migrations**: Array-level copy operations are significantly faster than network-based transfers
|
||||
- **Reduced network load**: Data doesn't traverse the network between VMware and PCD.
|
||||
- **Lower ESXi host CPU usage**: The storage array handles the heavy lifting
|
||||
- **Ideal for large VMs**: Especially beneficial for VMs with large disks (hundreds of GB to TB)
|
||||
|
||||
### Requirements
|
||||
|
||||
- **Supported storage arrays**: Pure Storage FlashArray or NetApp ONTAP
|
||||
- **Shared storage**: Both VMware datastores and PCD must be backed by the same storage array.
|
||||
- **ESXi SSH access**: SSH access to ESXi hosts with root privileges
|
||||
- **Storage connectivity**: ESXi hosts must be connected to the storage array via iSCSI (initiators configured) or Fibre Channel
|
||||
|
||||
## Supported Storage Arrays
|
||||
|
||||
| Vendor | Product |
|
||||
|--------|---------|
|
||||
| Pure Storage | FlashArray |
|
||||
| NetApp | ONTAP |
|
||||
|
||||
:::note
|
||||
Additional storage vendors may be added in future releases. The storage SDK is designed to be extensible.
|
||||
:::
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before using Storage-Accelerated Copy, ensure the following prerequisites are met:
|
||||
|
||||
### 1. Storage Array Configuration
|
||||
|
||||
- Storage array must be accessible from both VMware ESXi hosts and PCD compute nodes
|
||||
- VMware datastores must be VMFS volumes backed by LUNs on the supported storage array
|
||||
- PCD Cinder must be configured with a backend driver for the same storage array
|
||||
- Cinder volume types must be created and mapped to the storage array backend
|
||||
|
||||
### 2. ESXi SSH Access
|
||||
|
||||
Storage-Accelerated Copy requires SSH access to ESXi hosts to execute `vmkfstools` commands. Follow these steps to set up SSH access:
|
||||
|
||||
#### Step 1: Enable SSH on ESXi Hosts
|
||||
|
||||
**Option A: Using vSphere Client (GUI)**
|
||||
|
||||
1. Log in to vSphere Client
|
||||
2. Navigate to the ESXi host
|
||||
3. Click on the **Configure** tab
|
||||
4. Under **System**, select **Services**
|
||||
5. Find **SSH** in the list of services
|
||||
6. Right-click on **SSH** and select **Start**
|
||||
7. (Optional) Right-click again and select **Policy** → **Start and stop with host** to enable SSH automatically on boot
|
||||
|
||||
**Option B: Using ESXi Host Client (Direct)**
|
||||
|
||||
1. Log in to the ESXi host directly via web browser: `https://<esxi-host-ip>`
|
||||
2. Navigate to **Host** → **Actions** → **Services** → **Enable Secure Shell (SSH)**
|
||||
|
||||
**Option C: Using ESXi Shell (Console)**
|
||||
|
||||
1. Access the ESXi host console (physical or via iLO/iDRAC)
|
||||
2. Press `F2` to customize system/view logs
|
||||
3. Log in with root credentials
|
||||
4. Navigate to **Troubleshooting Options**
|
||||
5. Select **Enable SSH**
|
||||
6. Press `Enter` to confirm
|
||||
|
||||
#### Step 2: Generate SSH Key Pair
|
||||
|
||||
On your workstation or the vJailbreak VM, generate an SSH key pair:
|
||||
|
||||
```bash
|
||||
# Generate RSA key pair (recommended for ESXi compatibility)
|
||||
ssh-keygen -t rsa -b 4096 -f ~/.ssh/esxi_migration_key -C "vjailbreak-migration"
|
||||
|
||||
# When prompted:
|
||||
# - Enter passphrase: Leave empty (press Enter) for passwordless authentication
|
||||
# - Confirm passphrase: Press Enter again
|
||||
```
|
||||
|
||||
This will create two files:
|
||||
- `~/.ssh/esxi_migration_key` - Private key (keep this secure)
|
||||
- `~/.ssh/esxi_migration_key.pub` - Public key (to be copied to ESXi)
|
||||
|
||||
:::caution
|
||||
**Use RSA keys, not Ed25519**
|
||||
|
||||
Ed25519 keys are not reliably accepted for passwordless authentication on ESXi 8.x. Even with the public key correctly installed in `/etc/ssh/keys-root/authorized_keys` (correct permissions, `PubkeyAuthentication` enabled, SSH restarted), the host may keep prompting for a password. Use the 4096-bit RSA key shown above, which works for passwordless SSH across supported ESXi versions.
|
||||
:::
|
||||
|
||||
#### Step 3: Copy Public Key to ESXi Hosts
|
||||
|
||||
**Option A: Using ssh-copy-id (Easiest)**
|
||||
|
||||
```bash
|
||||
# Copy public key to ESXi host
|
||||
ssh-copy-id -i ~/.ssh/esxi_migration_key.pub root@<esxi-host-ip>
|
||||
|
||||
# Enter the root password when prompted
|
||||
```
|
||||
|
||||
**Option B: Manual Copy**
|
||||
|
||||
If `ssh-copy-id` is not available:
|
||||
|
||||
```bash
|
||||
# Display the public key
|
||||
cat ~/.ssh/esxi_migration_key.pub
|
||||
|
||||
# SSH into the ESXi host
|
||||
ssh root@<esxi-host-ip>
|
||||
|
||||
# On the ESXi host, add the public key to authorized_keys
|
||||
cat >> /etc/ssh/keys-root/authorized_keys << 'EOF'
|
||||
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC... vjailbreak-migration
|
||||
EOF
|
||||
|
||||
# Set correct permissions
|
||||
chmod 600 /etc/ssh/keys-root/authorized_keys
|
||||
```
|
||||
|
||||
#### Step 4: Test SSH Connection
|
||||
|
||||
Verify passwordless SSH access works:
|
||||
|
||||
```bash
|
||||
# Test SSH connection (should not prompt for password)
|
||||
ssh -i ~/.ssh/esxi_migration_key root@<esxi-host-ip>
|
||||
|
||||
```
|
||||
|
||||
If successful, you should be able to login to esxi.
|
||||
#### Step 5: Configure SSH Key in vJailbreak
|
||||
|
||||
1. Navigate to **Storage Management** page
|
||||
2. At the top, find the **ESXi SSH Key** section
|
||||
3. Click **Configure**
|
||||
4. Get your private key contents:
|
||||
```bash
|
||||
cat ~/.ssh/esxi_migration_key
|
||||
```
|
||||
5. Copy the entire output (including `-----BEGIN OPENSSH PRIVATE KEY-----` and `-----END OPENSSH PRIVATE KEY-----`)
|
||||
6. Paste into the UI textarea
|
||||
7. Click **Save**
|
||||
|
||||
#### Step 6: Repeat for All ESXi Hosts
|
||||
|
||||
Repeat Steps 3-4 for **all ESXi hosts** in your vCenter cluster that host VMs you plan to migrate. The same SSH key pair can be used for all hosts.
|
||||
|
||||
```bash
|
||||
# Example: Copy to multiple hosts
|
||||
for host in esxi-host1.example.com esxi-host2.example.com esxi-host3.example.com; do
|
||||
echo "Configuring $host..."
|
||||
ssh-copy-id -i ~/.ssh/esxi_migration_key.pub root@$host
|
||||
done
|
||||
```
|
||||
|
||||
:::caution
|
||||
**Security Best Practices:**
|
||||
- Use a dedicated SSH key pair for vJailbreak migrations (don't reuse existing keys)
|
||||
- Store the private key securely and restrict access
|
||||
- Consider disabling SSH on ESXi hosts after migrations are complete
|
||||
- Use SSH key passphrases in production environments (requires additional configuration)
|
||||
- Regularly rotate SSH keys
|
||||
- Monitor SSH access logs on ESXi hosts
|
||||
:::
|
||||
|
||||
:::note
|
||||
**Troubleshooting SSH Issues:**
|
||||
|
||||
If SSH connection fails:
|
||||
1. Verify SSH service is running: `ssh root@<esxi-host> "/etc/init.d/ssh status"`
|
||||
2. Check firewall rules: ESXi firewall must allow SSH (port 22)
|
||||
3. Verify authorized_keys permissions: Should be `600` or `400`
|
||||
4. Check ESXi logs: `/var/log/auth.log` for authentication errors
|
||||
5. Ensure the private key format is correct (OpenSSH format, not PuTTY format)
|
||||
:::
|
||||
|
||||
### 3. Network Connectivity
|
||||
|
||||
| Source | Destination | Port | Protocol | Purpose |
|
||||
|--------|-------------|------|----------|---------|
|
||||
| vJailbreak | ESXi hosts | 22 | TCP | SSH for vmkfstools commands |
|
||||
| ESXi hosts | Storage array | 3260 | TCP | iSCSI (if using iSCSI) |
|
||||
| ESXi hosts | Storage array | Various | FC | Fibre Channel (if using FC) |
|
||||
| vJailbreak | Storage array | 443 | TCP | Storage array API |
|
||||
|
||||
## Configuration
|
||||
|
||||
### Understanding Auto-Discovery
|
||||
|
||||
When you add PCD credentials to vJailbreak, the system automatically discovers all storage volume backends configured in your PCD environment. For each detected storage backend (NetApp, Pure Storage, etc.), vJailbreak creates a placeholder ArrayCreds entry with status "Auto-discovered" and credentials marked as "Pending".
|
||||
|
||||
#### How Auto-Discovery Works
|
||||
|
||||
1. **PCD Configuration**: In PCD, you configure multiple storage volume backends under "Persistent Storage Connectivity" (Cluster Blueprint → Storage). Each volume backend represents a storage array with its driver type (NetApp Data ONTAP, Pure Storage iSCSI, NFS, etc.).
|
||||
|
||||
2. **Backend Detection**: When PCD credentials are added to vJailbreak, the system queries the Cinder API to discover all configured volume backends and their properties:
|
||||
- Volume Type (e.g., `netapp`, `vt-pure-iscsi`)
|
||||
- Backend Name (e.g., `netapp`, `pure-iscsi-1`)
|
||||
- Driver Type (e.g., `NetApp Data ONTAP`, `Pure Storage iSCSI`)
|
||||
- Cinder Host string
|
||||
|
||||
3. **Placeholder Creation**: For each discovered backend, vJailbreak automatically creates an ArrayCreds resource with:
|
||||
- **Name**: Derived from the volume type and backend name (e.g., `netapp-netapp`, `vt-pure-iscsi-pure-iscsi-1`)
|
||||
- **Vendor**: Automatically identified from the driver type
|
||||
- **Source**: Marked as "Auto-discovered"
|
||||
- **Credentials**: Status shows "Pending" (requires user input)
|
||||
- **PCD Mapping**: Pre-populated with volume type, backend name, and Cinder host
|
||||
|
||||
4. **User Completion**: Users then update these auto-discovered entries with the actual storage array credentials (hostname, username, password) to enable Storage Accelerated Copy.
|
||||
|
||||
#### Storage Management Page
|
||||
|
||||
The Storage Management page displays all auto-discovered storage backends:
|
||||
|
||||
| Column | Description |
|
||||
|--------|-------------|
|
||||
| **Name** | Auto-generated name based on volume type and backend |
|
||||
| **Vendor** | Storage array vendor (NetApp Storage, Pure Storage, N/A) |
|
||||
| **Volume Type** | Cinder volume type name |
|
||||
| **Backend Name** | Cinder backend name from configuration |
|
||||
| **Source** | "Auto-discovered" for automatically detected backends |
|
||||
| **Credentials** | "Pending" until user provides array credentials |
|
||||
| **Actions** | Edit (to add credentials) and Delete |
|
||||
|
||||
|
||||
|
||||
#### Example: PCD with Multiple Storage Backends
|
||||
|
||||
In PCD, storage backends are configured in the **Cluster Blueprint** under **Persistent Storage Connectivity**. Each volume backend can have multiple configurations, and each configuration represents a connection to a storage array.
|
||||
|
||||
|
||||
|
||||
In the example above, PCD has three volume backends configured:
|
||||
1. **nfs** - NFS backend with driver "NFS"
|
||||
2. **netapp** - NetApp backend with driver "NetApp Data ONTAP"
|
||||
3. **vt-pure-iscsi** - Pure Storage backend with driver "Pure Storage iSCSI"
|
||||
|
||||
Each backend can have multiple configurations (shown as "Volume Backend Configurations" with the + button). For example:
|
||||
- The `nfs` volume backend might have one configuration named `nfs-backend`
|
||||
- The `netapp` volume backend might have one configuration named `netapp`
|
||||
- The `vt-pure-iscsi` volume backend might have multiple configurations: `pure-iscsi-1`, `pure-iscsi-2`, etc.
|
||||
|
||||
**Important**: For each volume type, you can configure multiple storage arrays. This is useful when you have multiple Pure Storage or NetApp arrays in your environment, each serving different datastores.
|
||||
|
||||
```
|
||||
Storage Volume Backend Configuration (Example):
|
||||
├── nfs (Volume Type)
|
||||
│ └── nfs-backend (Backend Configuration)
|
||||
│ ├── Driver: NFS
|
||||
│ └── Backend Name: nfs-backend
|
||||
├── netapp (Volume Type)
|
||||
│ └── netapp (Backend Configuration)
|
||||
│ ├── Driver: NetApp Data ONTAP
|
||||
│ └── Backend Name: netapp
|
||||
└── vt-pure-iscsi (Volume Type)
|
||||
├── pure-iscsi-1 (Backend Configuration #1)
|
||||
│ ├── Driver: Pure Storage iSCSI
|
||||
│ └── Backend Name: pure-iscsi-1
|
||||
└── pure-iscsi-2 (Backend Configuration #2)
|
||||
├── Driver: Pure Storage iSCSI
|
||||
└── Backend Name: pure-iscsi-2
|
||||
```
|
||||
|
||||
After adding PCD credentials to vJailbreak, the system automatically creates ArrayCreds placeholders for each backend configuration:
|
||||
- `nfs-nfs-backend` (Vendor: N/A, Credentials: Pending) - *Cannot be used for Storage Accelerated Copy*
|
||||
- `netapp-netapp` (Vendor: NetApp Storage, Credentials: Pending)
|
||||
- `vt-pure-iscsi-pure-iscsi-1` (Vendor: Pure Storage, Credentials: Pending)
|
||||
- `vt-pure-iscsi-pure-iscsi-2` (Vendor: Pure Storage, Credentials: Pending)
|
||||
|
||||
:::tip
|
||||
Only storage backends with supported vendors (Pure Storage and NetApp) can be configured for array-level XCOPY operations. NFS and other backends are still auto-discovered, but cannot be used for Storage Accelerated Copy. Support for additional storage vendors will be added in future releases.
|
||||
:::
|
||||
|
||||
## Using the UI
|
||||
|
||||
Storage-Accelerated Copy can be configured entirely through the vJailbreak UI with automatic backend discovery:
|
||||
|
||||
### Step 1: Add PCD Credentials
|
||||
|
||||
If not already done:
|
||||
1. Navigate to **Credentials** → **PCD/OpenStack**
|
||||
2. Add your PCD credentials
|
||||
3. vJailbreak will automatically discover all storage volume backends configured in PCD
|
||||
|
||||
### Step 2: Configure Storage Array Credentials
|
||||
|
||||
1. Navigate to **Storage Management** (Beta feature)
|
||||
2. You'll see auto-discovered entries for each PCD storage backend:
|
||||
- **Name**: Auto-generated (e.g., `netapp-netapp`, `vt-pure-iscsi-pure-iscsi-1`)
|
||||
- **Vendor**: Auto-identified from driver type
|
||||
- **Volume Type**: Pre-populated from PCD configuration
|
||||
- **Backend Name**: Pre-populated from PCD configuration
|
||||
- **Source**: "Auto-discovered"
|
||||
- **Credentials**: "Pending" (requires your input)
|
||||
|
||||
3. Click the **Edit** icon for a storage array entry
|
||||
|
||||
|
||||
|
||||
4. Fill in the storage array credentials:
|
||||
- **Hostname/IP**: Storage array management IP address
|
||||
- **Username**: Array administrator username
|
||||
- **Password**: Array administrator password
|
||||
- **Skip SSL Verification**: Enable for testing environments (disable in production)
|
||||
5. Click **Save**
|
||||
6. The system will:
|
||||
- Validate the credentials
|
||||
- Connect to the storage array
|
||||
- Auto-discover VMware datastores backed by this array
|
||||
- Update the status to show validation results
|
||||
|
||||
### Step 3: Configure ESXi SSH Key
|
||||
|
||||
1. At the top of the Storage Management page, find the **ESXi SSH Key** section
|
||||
2. Click **Configure** if not already configured
|
||||
3. Paste your ESXi SSH private key (see [ESXi SSH Access](#2-esxi-ssh-access) section for key generation steps)
|
||||
4. Click **Save**
|
||||
|
||||
### Step 4: Create Migration with Storage-Accelerated Copy
|
||||
|
||||
1. When creating a migration plan, select **Storage-Accelerated Copy** as the storage copy method
|
||||
|
||||
|
||||
|
||||
2. The UI will automatically map datastores to ArrayCreds if everything is configured correctly
|
||||
3. Start the migration - it will use array-level XCOPY for data transfer
|
||||
|
||||
:::note
|
||||
**Auto-Discovery Benefits:**
|
||||
- No manual typing of volume types, backend names, or Cinder host strings
|
||||
- Automatic vendor identification from driver type
|
||||
- Pre-populated PCD mapping configuration
|
||||
- Automatic datastore-to-array mapping
|
||||
- Reduced configuration errors
|
||||
:::
|
||||
|
||||
## Migration Workflow
|
||||
|
||||
When Storage-Accelerated Copy is enabled, the migration follows this workflow:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Storage-Accelerated Copy Flow │
|
||||
├─────────────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ 1. Validate Prerequisites │
|
||||
│ ├── Storage provider credentials │
|
||||
│ ├── ESXi SSH key │
|
||||
│ └── Array connectivity │
|
||||
│ │
|
||||
│ 2. Connect to ESXi Host via SSH │
|
||||
│ │
|
||||
│ 3. Power Off Source VM (required for XCOPY) │
|
||||
│ │
|
||||
│ 4. For Each Disk: │
|
||||
│ ├── Create target volume on storage array │
|
||||
│ ├── Import volume to Cinder (manage existing) │
|
||||
│ ├── Create/update initiator group with ESXi IQN │
|
||||
│ ├── Map volume to ESXi host │
|
||||
│ ├── Rescan ESXi storage adapters │
|
||||
│ ├── Wait for target device to appear │
|
||||
│ ├── Execute vmkfstools XCOPY clone │
|
||||
│ └── Monitor clone progress │
|
||||
│ │
|
||||
│ 5. Convert Volumes (same as normal migration) │
|
||||
│ │
|
||||
│ 6. Create Target VM in PCD │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Migration Phases
|
||||
|
||||
When using Storage-Accelerated Copy, you'll see these additional migration phases:
|
||||
|
||||
| Phase | Description |
|
||||
|-------|-------------|
|
||||
| `ConnectingToESXi` | Establishing SSH connection to ESXi host |
|
||||
| `CreatingInitiatorGroup` | Creating/updating initiator group on storage array |
|
||||
| `CreatingVolume` | Creating target volume on storage array |
|
||||
| `ImportingToCinder` | Importing volume to PCD Cinder |
|
||||
| `MappingVolume` | Mapping volume to ESXi host |
|
||||
| `RescanningStorage` | Rescanning ESXi storage adapters |
|
||||
| `StorageAcceleratedCopyInProgress` | XCOPY clone operation in progress |
|
||||
|
||||
## Limitations
|
||||
|
||||
- **Cold migration only**: VMs must be powered off during the copy operation (no live migration support)
|
||||
- **Shared storage required**: Source and destination must be on the same storage array
|
||||
- **VMFS datastores only**: NFS datastores are not supported
|
||||
- **No CBT support**: Change Block Tracking is not used; full disk copy is performed
|
||||
- **Single array per datastore**: Each datastore can only be mapped to one ArrayCreds
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
#### ESXi SSH Connection Failed
|
||||
|
||||
```
|
||||
Error: failed to connect to ESXi via SSH
|
||||
```
|
||||
|
||||
**Resolution**:
|
||||
- Verify SSH is enabled on the ESXi host
|
||||
- Check that the SSH private key is correctly stored in the `esxi-ssh-key` secret
|
||||
- Ensure network connectivity between vJailbreak and ESXi host on port 22
|
||||
|
||||
#### Storage Array Connection Failed
|
||||
|
||||
**Symptoms:**
|
||||
```
|
||||
Error: failed to connect to storage array: authentication failed
|
||||
```
|
||||
|
||||
**Solutions:**
|
||||
1. Verify credentials in the Storage Management UI:
|
||||
- Navigate to **Storage Management**
|
||||
- Check the array credentials are correct
|
||||
- Re-enter credentials if needed
|
||||
|
||||
2. Test connectivity from vJailbreak to storage array:
|
||||
- Ensure network connectivity on port 443 (HTTPS)
|
||||
- Check firewall rules between vJailbreak and storage array
|
||||
- Verify API access is enabled on the array
|
||||
|
||||
3. Check array-specific requirements:
|
||||
- **Pure Storage**: Ensure API token or username/password has sufficient permissions
|
||||
- **NetApp**: Verify ONTAP management interface is accessible
|
||||
|
||||
#### ESXi Device Not Found
|
||||
|
||||
**Symptoms:**
|
||||
```
|
||||
Error: timeout waiting for device naa.624a9370... to appear on ESXi host
|
||||
```
|
||||
|
||||
**Solutions:**
|
||||
1. Verify iSCSI initiator is configured on ESXi:
|
||||
- Log into ESXi via SSH
|
||||
- Run: `esxcli iscsi adapter list`
|
||||
- Ensure iSCSI software adapter is enabled
|
||||
|
||||
2. Check network connectivity from ESXi to storage array:
|
||||
- Verify ESXi can reach storage array management IP
|
||||
- Check iSCSI network configuration
|
||||
- Verify VLAN/network segmentation allows iSCSI traffic
|
||||
|
||||
3. Manually rescan storage:
|
||||
```bash
|
||||
esxcli storage core adapter rescan --all
|
||||
esxcli storage core device list | grep naa.624a9370
|
||||
```
|
||||
|
||||
4. Verify LUN masking/mapping on the storage array:
|
||||
- Check initiator group includes ESXi IQN
|
||||
- Verify volume is mapped to the correct initiator group
|
||||
- Check for iSCSI authentication issues (CHAP)
|
||||
|
||||
#### Cinder Manage Volume Failed
|
||||
|
||||
**Symptoms:**
|
||||
```
|
||||
Error: failed to manage existing volume: volume not found on backend
|
||||
```
|
||||
|
||||
**Solutions:**
|
||||
1. Verify volume exists on the storage array:
|
||||
- Check storage array management interface
|
||||
- Confirm volume was created successfully
|
||||
|
||||
2. Check Cinder backend configuration:
|
||||
- Verify Cinder services are running in PCD
|
||||
- Ensure volume backend name matches ArrayCreds configuration
|
||||
- Check that the Cinder host string is correct
|
||||
|
||||
3. Ensure volume naming matches backend expectations:
|
||||
- **Pure Storage**: Volume name must match exactly
|
||||
- **NetApp**: Full LUN path must be provided
|
||||
|
||||
4. Review Cinder logs for detailed errors:
|
||||
- Check PCD Cinder volume service logs
|
||||
- Look for backend connection issues
|
||||
- Verify the `cinderHost` field in ArrayCreds matches a running Cinder service
|
||||
|
||||
#### vmkfstools Clone Failed
|
||||
|
||||
**Symptoms:**
|
||||
```
|
||||
Error: vmkfstools clone failed: Unable to create raw disk
|
||||
```
|
||||
|
||||
**Solutions:**
|
||||
1. Check ESXi SSH connectivity and authentication:
|
||||
- Verify SSH key is configured correctly in vJailbreak
|
||||
- Test SSH connection manually
|
||||
- Check ESXi SSH service is running
|
||||
|
||||
2. Verify vmkfstools is available:
|
||||
```bash
|
||||
vmkfstools --version
|
||||
```
|
||||
|
||||
3. Check source VMDK accessibility:
|
||||
```bash
|
||||
ls -lh /vmfs/volumes/<datastore>/<vm-name>/<disk>.vmdk
|
||||
```
|
||||
|
||||
4. Verify target device is visible:
|
||||
```bash
|
||||
ls -lh /vmfs/devices/disks/naa.*
|
||||
```
|
||||
|
||||
5. Check ESXi host logs:
|
||||
```bash
|
||||
tail -f /var/log/vmkernel.log
|
||||
```
|
||||
|
||||
6. Ensure sufficient free space on ESXi:
|
||||
- RDM descriptor files require space on the datastore
|
||||
- Check datastore free space
|
||||
|
||||
#### Clone Progress Stalled
|
||||
|
||||
**Symptoms:**
|
||||
```
|
||||
Error: clone progress stalled - no update for 5 minutes
|
||||
```
|
||||
|
||||
**Solutions:**
|
||||
1. Check storage array performance and load:
|
||||
- Review array management interface for performance metrics
|
||||
- Check for high I/O load or resource contention
|
||||
- Verify no array-level issues or alerts
|
||||
|
||||
2. Verify ESXi storage adapter health:
|
||||
```bash
|
||||
esxcli storage core adapter list
|
||||
```
|
||||
|
||||
3. Review vmkfstools process on ESXi:
|
||||
```bash
|
||||
ps | grep vmkfstools
|
||||
ps -c | grep vmkfstools
|
||||
```
|
||||
- Check if process is still running
|
||||
- Look for any error indicators
|
||||
|
||||
4. Check for network issues:
|
||||
- Verify stable connectivity between ESXi and storage array
|
||||
- Check for packet loss or latency issues
|
||||
|
||||
5. Consider increasing timeout settings:
|
||||
- For very large disks, the operation may take longer than expected
|
||||
- Monitor array performance to ensure copy is progressing
|
||||
|
||||
### Checking ArrayCreds Status
|
||||
|
||||
You can check the status of your storage array credentials in the UI:
|
||||
|
||||
1. Navigate to **Storage Management**
|
||||
2. Check the **Credentials** column - it should show "Valid" after successful configuration
|
||||
3. The system will display discovered datastores for each array
|
||||
4. Any validation errors will be shown in the status column
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Validate prerequisites first**: Ensure all connectivity and credentials are working before starting migrations
|
||||
2. **Schedule during maintenance windows**: VMs must be powered off during copy
|
||||
3. **Monitor array performance**: Large migrations can impact array performance
|
||||
4. **Use for large VMs**: The setup overhead makes this most beneficial for VMs with large disks
|
||||
5. **Batch similar VMs**: Group VMs on the same datastore for efficient migrations
|
||||
@@ -0,0 +1,111 @@
|
||||
---
|
||||
title: "User Credential Management"
|
||||
description: "A guide on how to manage user credentials using vjailbreak CLI."
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Use `vjbctl` to manage user credentials: list users, delete users, change passwords, and refresh credentials.
|
||||
|
||||
## Assumptions
|
||||
|
||||
Before you start, ensure the following prerequisites are fulfilled:
|
||||
|
||||
- vJailbreak is installed and configured properly.
|
||||
|
||||
## Command Reference
|
||||
|
||||
The following commands are available for user credential management:
|
||||
|
||||
```bash
|
||||
# List users
|
||||
vjbctl user list
|
||||
|
||||
# create a new user
|
||||
vjbctl user create <username>
|
||||
|
||||
# Delete a user
|
||||
vjbctl user delete <username>
|
||||
|
||||
# Change a user's password
|
||||
vjbctl user change-password <username>
|
||||
|
||||
# Refresh user credentials
|
||||
vjbctl user refresh
|
||||
```
|
||||
|
||||
> Tip: Append `--no-restart` to `vjbctl user` subcommands (e.g., `create`, `delete`, `change-password`) to defer applying changes. Then run `vjbctl user refresh` once to apply all pending changes for better efficiency.
|
||||
|
||||
## Usage
|
||||
|
||||
> Note: After any user change (e.g., password updates or deletions), run `vjbctl user refresh` for the changes to be reflected.
|
||||
|
||||
### List users
|
||||
|
||||
```bash
|
||||
vjbctl user list
|
||||
```
|
||||
|
||||
### Delete a user
|
||||
|
||||
Delete a user and remove their credentials from the system:
|
||||
|
||||
```bash
|
||||
vjbctl user delete <username>
|
||||
```
|
||||
|
||||
### Change a user's password
|
||||
|
||||
Change the password for an existing user:
|
||||
|
||||
```bash
|
||||
vjbctl user change-password <username>
|
||||
```
|
||||
|
||||
You will be prompted to enter the new password in the terminal.
|
||||
|
||||
### Batch multiple changes efficiently
|
||||
|
||||
To avoid refreshing after every change, you can batch multiple operations using `--no-restart` and then apply them all at once with a single refresh:
|
||||
|
||||
```bash
|
||||
# Defer applying changes while making multiple updates
|
||||
vjbctl user create <username> --no-restart
|
||||
vjbctl user change-password <username> --no-restart
|
||||
vjbctl user delete <username> --no-restart
|
||||
|
||||
# Apply all pending changes
|
||||
vjbctl user refresh
|
||||
```
|
||||
|
||||
### Refresh user credentials
|
||||
|
||||
Refresh user credentials for active users:
|
||||
|
||||
```bash
|
||||
vjbctl user refresh
|
||||
```
|
||||
|
||||
## Examples
|
||||
|
||||
The following sequence demonstrates a typical workflow for updating user credentials:
|
||||
|
||||
```bash
|
||||
# Inspect existing users
|
||||
vjbctl user list
|
||||
|
||||
# Create a new user
|
||||
vjbctl user create john.doe
|
||||
# For changes to be reflected, refresh
|
||||
vjbctl user refresh
|
||||
|
||||
# Update password for a specific user
|
||||
vjbctl user change-password jane.doe
|
||||
# For changes to be reflected, refresh
|
||||
vjbctl user refresh
|
||||
|
||||
# Remove a deprovisioned user
|
||||
vjbctl user delete temp.user
|
||||
# For changes to be reflected, refresh
|
||||
vjbctl user refresh
|
||||
```
|
||||
@@ -0,0 +1,461 @@
|
||||
---
|
||||
title: vJailbreak Accelerated Copy
|
||||
description: High-performance VM migration using a Proxy VM for direct disk attachment and NBD-based data transfer
|
||||
---
|
||||
|
||||
vJailbreak Accelerated Copy is an advanced data copy method that attaches source VM disks directly to a dedicated Proxy VM and streams the data over NBD (Network Block Device) to the destination. Instead of copying data over the NFC protocol from ESXi, this method leverages vCenter's disk-attach capability to transfer data at near-disk speeds without requiring shared storage arrays.
|
||||
|
||||
> **Underlying feature:** vJailbreak Accelerated Copy is powered by VMware's **hot-add** disk transport mechanism to attach source disks to the Proxy VM.
|
||||
|
||||
:::danger[Cold migration only: hot data copy is not supported]
|
||||
vJailbreak Accelerated Copy **does not support live (hot) migration**. The source VM is powered off
|
||||
before its disks are attached to the Proxy VM. You must select **"Power off VMs, then copy"** as
|
||||
the Data Copy Method when using vJailbreak Accelerated Copy. Attempting to use it with
|
||||
**"Copy live VMs, then power off"** is not supported.
|
||||
:::
|
||||
|
||||
:::note[VDDK not required]
|
||||
As of v0.4.10, vJailbreak Accelerated Copy does not require VDDK at any stage. Data is transferred
|
||||
directly via the hot-add disk transport and NBD streaming. VDDK is never used. This makes it the
|
||||
recommended copy method when VMware's VDDK download pages are unavailable.
|
||||
:::
|
||||
|
||||
## Overview
|
||||
|
||||
### How It Works
|
||||
|
||||
Traditional vJailbreak migrations copy VM disk data from VMware ESXi hosts to PCD Cinder volumes over the network using the NFC (Network File Copy) protocol, limited to approximately **1 Gbps per VMDK**.
|
||||
|
||||
vJailbreak Accelerated Copy bypasses this limitation by:
|
||||
|
||||
1. Powering off the source VM and then taking a snapshot
|
||||
2. Attaching the frozen snapshot disks directly to a Proxy VM running in vCenter
|
||||
3. Identifying each disk as a block device inside the Proxy VM using disk UUID matching
|
||||
4. Exposing each disk as an NBD resource on the Proxy VM via `qemu-nbd`
|
||||
5. Running `nbdcopy` on the vJailbreak VM to pull data from the Proxy VM directly to the destination Cinder volume
|
||||
|
||||
### Benefits
|
||||
|
||||
- **Faster migrations**: Direct block-device access avoids NFC protocol overhead
|
||||
- **No shared storage required**: Works with any datastore — NFS, VMFS, vSAN
|
||||
- **Lower ESXi host load**: Data is streamed from the Proxy VM, not the ESXi NFC daemon
|
||||
|
||||
### Requirements
|
||||
|
||||
- **Proxy VM**: A Linux VM running in the same vCenter with `qemu-nbd` and `openssh-server` installed
|
||||
- **SSH access**: vJailbreak must be able to SSH into the Proxy VM as root
|
||||
- **Open ports**: The Proxy VM must accept inbound TCP from the vJailbreak VM on **22** (SSH) and **10809–11808** (`qemu-nbd`, one port per disk copied in parallel)
|
||||
- **disk.EnableUUID**: Must be set to `TRUE` on the Proxy VM in vCenter
|
||||
- **PVSCSI controller**: The Proxy VM's first SCSI controller (**SCSI controller 0**) must be of type **VMware Paravirtual (PVSCSI)**
|
||||
- **Datastore accessibility**: The HotAdd proxy must have access to the same datastore as the target virtual machine, and the VMFS version and data block sizes for the target VM must be the same as the datastore where the HotAdd proxy resides.
|
||||
- **vCenter permissions**: Sufficient permissions to snapshot VMs and attach/detach disks
|
||||
|
||||
## Prerequisites
|
||||
|
||||
### 1. Proxy VM Requirements
|
||||
|
||||
The Proxy VM must have the following utilities installed and running:
|
||||
|
||||
| Utility | Purpose |
|
||||
|---------|---------|
|
||||
| `openssh-server` | SSH connectivity for vJailbreak to control the Proxy VM |
|
||||
| `qemu-nbd` | Expose attached block devices as NBD resources |
|
||||
|
||||
The Proxy VM must be a **Linux-based OS** (recommended: Ubuntu, Alpine, or Debian) with **root SSH access** enabled.
|
||||
|
||||
### 2. vCenter Requirements
|
||||
|
||||
- The Proxy VM must have **disk.EnableUUID = TRUE** set in vCenter VM settings
|
||||
- The Proxy VM's **SCSI controller 0** must be of type **VMware Paravirtual (PVSCSI)**
|
||||
- vCenter must allow disk attach/detach operations on the Proxy VM
|
||||
- The Proxy VM must be powered on and reachable over SSH
|
||||
- The Proxy VM must be on the same datastore as the source VM's disks, with a matching VMFS version and block size (see **Datastore accessibility** under [Requirements](#requirements))
|
||||
|
||||
|
||||
## Setting Up the Proxy VM
|
||||
|
||||
### Option A: Deploy from the vJailbreak UI (Easiest)
|
||||
|
||||
vJailbreak can deploy and register the Proxy VM in a single step directly from the UI:
|
||||
|
||||
1. Navigate to **vJailbreak Accelerated Copy** in the left sidebar
|
||||
2. Click **Add Proxy VM** and select **Deploy a new vJailbreak Proxy VM**
|
||||
3. Select your VMware credentials and fill in the deployment target (datacenter, datastore, network, and optionally a cluster or host)
|
||||
4. Enter a unique VM name and click **Deploy & Register VM**
|
||||
|
||||
vJailbreak will import the pre-configured OVA into vCenter, power the VM on, generate and inject an SSH key pair automatically, and register the Proxy VM — no manual key setup required. The VM appears in the list with status **Deploying** and transitions to **Ready** once verification completes (typically 3–5 minutes).
|
||||
|
||||
:::caution
|
||||
The OVA image uses default credentials (`root` / `password`) for the initial SSH key injection step. Change the root password on the VM after deployment in production environments.
|
||||
:::
|
||||
|
||||
:::caution[ESXi/vCenter version requirement]
|
||||
The bundled OVA uses virtual hardware version **vmx-21**, which requires **ESXi 8.0 U2 (vCenter 8.0 U2) or newer**. Deploying it to an older host fails with an "unsupported hardware family" error. On ESXi/vCenter 7.x, use **Option B** to register a manually created Linux VM instead.
|
||||
:::
|
||||
|
||||
### Option B: Register an Existing Linux VM
|
||||
|
||||
Any Linux VM can serve as the Proxy VM provided it meets the requirements. Install the necessary utilities:
|
||||
|
||||
**Ubuntu / Debian:**
|
||||
```bash
|
||||
sudo apt update
|
||||
sudo apt install -y openssh-server qemu-utils
|
||||
```
|
||||
|
||||
**Alpine:**
|
||||
```bash
|
||||
apk update
|
||||
apk add openssh qemu-nbd
|
||||
```
|
||||
|
||||
:::note
|
||||
Root access is required for SSH and for running `qemu-nbd` commands on the Proxy VM. Ensure `PermitRootLogin yes` is set in `/etc/ssh/sshd_config` if root SSH is not already enabled.
|
||||
:::
|
||||
|
||||
### Configure disk.EnableUUID on the Proxy VM
|
||||
|
||||
This setting is required for vJailbreak to match attached disks to their block devices inside the Proxy VM:
|
||||
|
||||
1. In vSphere Client, right-click the Proxy VM and select **Edit Settings**
|
||||
2. Click **VM Options** → **Advanced** → **Edit Configuration**
|
||||
3. Find or add the key `disk.EnableUUID` and set the value to `TRUE`
|
||||
4. Click **OK** and restart the VM if it was already running
|
||||
|
||||
### Configure the SCSI Controller Type on the Proxy VM
|
||||
|
||||
Source disks are attached to the Proxy VM's first SCSI controller, and vJailbreak can only match them to block devices when that controller is **VMware Paravirtual**:
|
||||
|
||||
1. Power off the Proxy VM
|
||||
2. In vSphere Client, right-click the Proxy VM and select **Edit Settings**
|
||||
3. Under **Virtual Hardware**, locate **SCSI controller 0**
|
||||
4. Set **Change Type** to **VMware Paravirtual**
|
||||
5. Click **OK** and power the VM back on
|
||||
|
||||
:::caution
|
||||
Other controller types — including **LSI Logic SAS**, **LSI Logic Parallel**, and **BusLogic Parallel** — are not supported. Migrations using a Proxy VM without PVSCSI on SCSI controller 0 fail with `could not identify block device for disk <uuid>`. See [Proxy VM Must Use a PVSCSI Controller](../../reference/known-limitations/#proxy-vm-must-use-a-pvscsi-controller).
|
||||
:::
|
||||
|
||||
## SSH Key Configuration
|
||||
|
||||
:::note
|
||||
This section applies to **Option B** (registering an existing VM). When using Option A (UI-based OVA deploy), SSH keys are generated and injected automatically — no manual key steps are needed.
|
||||
:::
|
||||
|
||||
When registering an existing VM, vJailbreak needs SSH access to the Proxy VM. The UI offers two ways to provide the key pair:
|
||||
|
||||
### Sub-option 1: Let vJailbreak Generate the Key Pair
|
||||
|
||||
1. In the **Add Proxy VM** drawer, select **Register an existing VM**
|
||||
2. Select your VMware credentials and the VM
|
||||
3. Under **SSH Access**, choose **Generate Key Pair** and click **Generate**
|
||||
4. The UI displays the public key — copy it and add it to the Proxy VM's `authorized_keys`:
|
||||
```bash
|
||||
# On the Proxy VM (as root)
|
||||
echo "<paste public key here>" >> ~/.ssh/authorized_keys
|
||||
chmod 600 ~/.ssh/authorized_keys
|
||||
```
|
||||
5. Click **Register**
|
||||
|
||||
vJailbreak stores the generated private key as a Kubernetes secret automatically.
|
||||
|
||||
### Sub-option 2: Upload Your Own Private Key
|
||||
|
||||
If you have an existing key pair already configured on the VM:
|
||||
|
||||
1. Under **SSH Access**, choose **Upload Private Key**
|
||||
2. Upload the private key file or paste its contents into the text area
|
||||
3. Confirm the corresponding public key is already in the VM's `authorized_keys`
|
||||
4. Click **Register**
|
||||
|
||||
vJailbreak stores the uploaded private key as a Kubernetes secret and uses it during verification and migration.
|
||||
|
||||
#### Generating a Key Pair Manually
|
||||
|
||||
If you prefer to generate the key pair yourself outside of vJailbreak:
|
||||
|
||||
```bash
|
||||
ssh-keygen -t rsa -b 4096 -f proxy_vm_key -N ""
|
||||
```
|
||||
|
||||
This produces two files:
|
||||
- `proxy_vm_key` — private key (upload this into vJailbreak)
|
||||
- `proxy_vm_key.pub` — public key (add this to the Proxy VM)
|
||||
|
||||
On the Proxy VM, append the public key to root's `authorized_keys`:
|
||||
|
||||
```bash
|
||||
# On the Proxy VM (as root)
|
||||
mkdir -p ~/.ssh
|
||||
cat >> ~/.ssh/authorized_keys << 'EOF'
|
||||
<contents of proxy_vm_key.pub>
|
||||
EOF
|
||||
chmod 600 ~/.ssh/authorized_keys
|
||||
```
|
||||
|
||||
If you have temporary password SSH access, you can use `ssh-copy-id` from your workstation as a shortcut:
|
||||
|
||||
```bash
|
||||
ssh-copy-id -i proxy_vm_key.pub root@<proxy-vm-ip>
|
||||
```
|
||||
|
||||
:::note
|
||||
**SSH key requirements:**
|
||||
- No passphrase — vJailbreak uses the key non-interactively
|
||||
- Any standard PEM format is accepted: RSA, EC, PKCS#8, or OpenSSH. PuTTY `.ppk` format is not supported
|
||||
- `PermitRootLogin` must be `yes` or `prohibit-password` in `/etc/ssh/sshd_config` on the Proxy VM
|
||||
:::
|
||||
|
||||
## Registering the Proxy VM in vJailbreak
|
||||
|
||||
Once the Proxy VM is set up and the SSH key is ready:
|
||||
|
||||
1. In the vJailbreak UI, navigate to **vJailbreak Accelerated Copy** in the left sidebar
|
||||
2. Click **Add Proxy VM**
|
||||
3. Fill in the form:
|
||||
- **Name**: A unique identifier for this Proxy VM
|
||||
- **VM Name**: The exact VM name as it appears in vCenter
|
||||
- **VMware Credentials**: Select the VMware credentials that can see this VM
|
||||
- **SSH Private Key**: Paste the contents of your private key file (e.g., `~/.ssh/proxy_vm_key`)
|
||||
4. Click **Add**
|
||||
|
||||
vJailbreak will verify the Proxy VM by:
|
||||
- Confirming the VM exists in vCenter
|
||||
- Retrieving the guest IP via VMware Tools
|
||||
- Checking `disk.EnableUUID = TRUE` — if not set, vJailbreak will automatically enable it and reboot the Proxy VM, so onboarding may take longer than usual
|
||||
- Establishing an SSH connection
|
||||
- Verifying `qemu-nbd` is available
|
||||
|
||||
The Proxy VM status will update to **Ready** once all checks pass. Any failed checks are reported with a specific error message in the UI.
|
||||
|
||||
:::tip
|
||||
If verification fails, address the reported issue (e.g., install missing utilities, fix SSH access) and click **Retry** to re-run the validation without re-entering the form.
|
||||
:::
|
||||
|
||||
## Using vJailbreak Accelerated Copy in a Migration
|
||||
|
||||
### Step 1: Create a Migration
|
||||
|
||||
1. Navigate to the **Migrations** page and click **New Migration**
|
||||
2. Fill out the migration form with source VM and target configuration
|
||||
3. For the **Data Copy Method**, select **vJailbreak Accelerated Copy**
|
||||
|
||||
### Step 2: Select Proxy VM
|
||||
|
||||
4. A **Proxy VM** dropdown appears — select a Proxy VM in **Ready** state
|
||||
5. The UI will only show Proxy VMs that are verified and ready
|
||||
|
||||
### Step 3: Start the Migration
|
||||
|
||||
6. Review **Advanced Options** if needed (network/storage mappings)
|
||||
7. Click **Start Migration**
|
||||
|
||||
:::note
|
||||
The selected Proxy VM must be in **Ready** state before the migration can proceed. If no Proxy VM is ready, register and verify one first.
|
||||
:::
|
||||
|
||||
## Migration Workflow
|
||||
|
||||
When vJailbreak Accelerated Copy is selected, the migration follows this workflow:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ vJailbreak Accelerated Copy Flow │
|
||||
├─────────────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ 1. Validate Prerequisites │
|
||||
│ ├── Proxy VM is in Ready state │
|
||||
│ ├── SSH connectivity to Proxy VM │
|
||||
│ └── qemu-nbd available on Proxy VM │
|
||||
│ │
|
||||
│ 2. Provision Destination Resources (standard workflow) │
|
||||
│ ├── Create Cinder volumes in PCD │
|
||||
│ └── Attach destination disks to vJailbreak VM │
|
||||
│ │
|
||||
│ 3. Power Off Source VM, then Take Snapshot │
|
||||
│ │
|
||||
│ 4. For Each Source Disk: │
|
||||
│ ├── Attach frozen snapshot disk to Proxy VM │
|
||||
│ ├── Identify block device via disk UUID matching │
|
||||
│ ├── Find a free port on the Proxy VM │
|
||||
│ ├── Expose disk as NBD via qemu-nbd on that port │
|
||||
│ ├── Run nbdcopy on vJailbreak VM to destination disk │
|
||||
│ └── Detach and clean up disk from Proxy VM │
|
||||
│ │
|
||||
│ 5. Remove Source VM Snapshot │
|
||||
│ │
|
||||
│ 6. Disk Conversion (same as normal migration) │
|
||||
│ │
|
||||
│ 7. Create Target VM in PCD (standard post-copy flow) │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Component Diagram
|
||||
|
||||
The pieces involved and how they talk to each other:
|
||||
|
||||
```mermaid
|
||||
architecture-beta
|
||||
service admin(internet)[Admin UI]
|
||||
|
||||
group vjb(cloud)[vJailbreak Appliance]
|
||||
service ctrl(server)[Controller] in vjb
|
||||
service pod(server)[Migration Pod] in vjb
|
||||
|
||||
group vmw(cloud)[VMware Environment]
|
||||
service vc(server)[vCenter] in vmw
|
||||
service proxy(server)[Proxy VM] in vmw
|
||||
|
||||
group pcd(cloud)[Platform9 PCD]
|
||||
service os(disk)[Cinder Volume] in pcd
|
||||
|
||||
admin:R -- L:ctrl
|
||||
ctrl:R -- L:vc
|
||||
ctrl:B -- T:proxy
|
||||
vc:B -- L:proxy
|
||||
pod:L -- R:proxy
|
||||
pod:B -- T:os
|
||||
```
|
||||
|
||||
- **Admin UI → Controller**: manage Proxy VMs and MigrationPlans (Kubernetes API)
|
||||
- **Controller → vCenter/ESXi**: deploy/register the Proxy VM (OVA import), read host inventory
|
||||
- **Controller → Proxy VM**: push/verify SSH key, confirm `qemu-nbd` and `disk.EnableUUID`
|
||||
- **vCenter/ESXi → Proxy VM**: hot-add the frozen source-VM disks
|
||||
- **Migration Pod → Proxy VM**: SSH — identify block devices, start `qemu-nbd`, run `nbdcopy`
|
||||
- **Migration Pod → Cinder Volume**: write the copied disk data to the destination
|
||||
|
||||
### Sequence Diagram
|
||||
|
||||
The same flow as a sequence diagram, including Proxy VM onboarding (only the operations specific to vJailbreak Accelerated Copy are shown — disk conversion and target VM creation follow the same path as every other copy method):
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
actor Admin
|
||||
participant Ctrl as vJailbreak Controller
|
||||
participant vC as vCenter / ESXi
|
||||
participant Proxy as Proxy VM
|
||||
participant Pod as Migration Pod (v2v-helper)
|
||||
participant OS as OpenStack (Cinder/Nova)
|
||||
|
||||
Note over Admin,OS: Onboarding — Option A: Deploy new Proxy VM (OVA)
|
||||
Admin->>Ctrl: Deploy & Register VM (OVA)
|
||||
Ctrl->>vC: Import OVA, power on VM
|
||||
Ctrl->>Proxy: Auto-generate & inject SSH keypair
|
||||
Ctrl->>Proxy: Verify SSH, qemu-nbd, disk.EnableUUID
|
||||
Ctrl->>Ctrl: Store private key as Secret "{proxyVM}-hot-add-ssh-key"
|
||||
Ctrl-->>Admin: Proxy VM ready
|
||||
|
||||
Note over Admin,OS: Onboarding — Option B: Register an existing VM
|
||||
Admin->>Ctrl: Register VM + SSH key (generate or upload)
|
||||
Note right of Admin: If generated, admin adds public key<br/>to the VM's authorized_keys manually
|
||||
Ctrl->>Proxy: Verify SSH, qemu-nbd, disk.EnableUUID
|
||||
Ctrl->>Ctrl: Store private key as Secret "{proxyVM}-hot-add-ssh-key"
|
||||
Ctrl-->>Admin: Proxy VM ready
|
||||
|
||||
Note over Admin,OS: Migration — vJailbreak Accelerated Copy
|
||||
Admin->>Ctrl: Create MigrationPlan (StorageCopyMethod=HotAdd)
|
||||
Ctrl->>Pod: Launch v2v-helper (Proxy VM IP + SSH secret)
|
||||
Pod->>vC: Power off source VM, take snapshot
|
||||
Pod->>vC: Hot-add frozen VMDKs to Proxy VM
|
||||
Pod->>Proxy: SSH — match disk WWID to block device
|
||||
Pod->>Proxy: SSH — start qemu-nbd per disk
|
||||
Proxy-->>Pod: nbdcopy streams disk over NBD
|
||||
Pod->>OS: Write stream into Cinder volume
|
||||
Pod->>vC: Detach disks, delete snapshot
|
||||
Pod-->>Ctrl: Migration succeeded
|
||||
```
|
||||
|
||||
## Limitations
|
||||
|
||||
- **Cold copy only**: The source VM is powered off before disk attachment — live (hot) copy of the running VM's active disks is not supported
|
||||
- **Same vCenter**: Proxy VM and source VM must be managed by the same vCenter instance
|
||||
- **VMware Tools required**: The Proxy VM must have VMware Tools running so vJailbreak can retrieve its guest IP
|
||||
- **PVSCSI controller only**: The Proxy VM's first SCSI controller (**SCSI controller 0**) must be **VMware Paravirtual (PVSCSI)**. Disk UUID matching does not work on other controller types, and migrations fail with `could not identify block device for disk <uuid>`. See [Configure the SCSI Controller Type](#configure-the-scsi-controller-type-on-the-proxy-vm).
|
||||
- **Concurrent disk attach can fail**: When several migrations reach the disk-attach step at the same time on the same Proxy VM, vCenter may reject some of the simultaneous reconfigure tasks and those migrations fail. This is a transient race — the migrations that attached first continue normally, and the failed ones succeed on retry. Stagger migration start times or spread migrations across multiple Proxy VMs to reduce the chance of it happening.
|
||||
- **Maximum 60 disks per Proxy VM (including its own boot disk)**: vSphere allows at most **60** virtual disks per VM (4 SCSI controllers × 15 disks). The Proxy VM's own boot disk counts toward this total, so the constraint is **Proxy VM boot disk + attached source disks ≤ 60** — a Proxy VM with a single boot disk can have up to **59** source disks attached at any one time. This is a shared ceiling across **all** migrations using the same Proxy VM concurrently, not a per-migration limit. To migrate more disks in parallel, register additional Proxy VMs and distribute migrations across them.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Proxy VM Verification Failed
|
||||
|
||||
**Symptoms:** Proxy VM stuck in `Pending` or `Failed` state with a validation error.
|
||||
|
||||
**Resolution by error:**
|
||||
|
||||
| Error | Resolution |
|
||||
|-------|-----------|
|
||||
| VM not found in vCenter | Verify the VM name exactly matches the vCenter inventory name |
|
||||
| Guest IP not available | Ensure VMware Tools is installed and running on the Proxy VM |
|
||||
| `disk.EnableUUID` not set | Set `disk.EnableUUID = TRUE` in VM advanced settings and reboot |
|
||||
| SSH connection refused | Verify `sshd` is running and port 22 is reachable from vJailbreak |
|
||||
| `qemu-nbd` not found | Install `qemu-utils` (Ubuntu) or `qemu-nbd` (Alpine) on the Proxy VM |
|
||||
|
||||
### NBD Connection Failed During Copy
|
||||
|
||||
```
|
||||
Error: failed to connect to NBD endpoint on proxy VM
|
||||
```
|
||||
|
||||
**Resolution:**
|
||||
1. Verify the Proxy VM is still running and SSH is accessible
|
||||
2. Check that `qemu-nbd` started successfully — review v2v helper logs
|
||||
3. Ensure the NBD ports (TCP **10809–11808**, one per disk copied in parallel) are not blocked by a firewall between the Proxy VM and vJailbreak
|
||||
4. Confirm the Proxy VM's guest IP is correct (VMware Tools must be running)
|
||||
|
||||
### Block Device Not Found in Proxy VM
|
||||
|
||||
```
|
||||
Error: could not identify block device for disk <uuid>
|
||||
```
|
||||
|
||||
**Resolution:**
|
||||
1. Verify `disk.EnableUUID = TRUE` is set on the Proxy VM (this is the most common cause)
|
||||
2. Verify the Proxy VM's **SCSI controller 0** is of type **VMware Paravirtual** — no other controller type is supported. See [Configure the SCSI Controller Type](#configure-the-scsi-controller-type-on-the-proxy-vm)
|
||||
3. Confirm the disk was actually attached — check vCenter → Proxy VM → Edit Settings → Hard Disks
|
||||
4. SSH into the Proxy VM and run `lsblk` to list visible block devices
|
||||
5. Check vCenter events for disk attach errors on the Proxy VM
|
||||
|
||||
### Disk Attach Fails When Several Migrations Start Together
|
||||
|
||||
**Symptoms:** A batch of migrations is started at once and some of them fail early with a vCenter error while attaching disks to the Proxy VM. The remaining migrations proceed into the copy phase normally.
|
||||
|
||||
**Cause:** vCenter does not always handle simultaneous VM reconfigure (disk attach) tasks on the same Proxy VM gracefully, so some attach requests are rejected. This is a transient race condition, not a misconfiguration.
|
||||
|
||||
**Resolution:**
|
||||
1. Wait until the surviving migrations have entered the copy phase
|
||||
2. [Retry](../../guides/how-to/retry_failed_migration/) the failed migrations — they normally succeed on the second attempt
|
||||
3. To reduce the chance of the race, stagger migration start times instead of starting a large batch at once, or register additional Proxy VMs and distribute migrations across them
|
||||
|
||||
### Snapshot Creation Failed
|
||||
|
||||
```
|
||||
Error: failed to create snapshot on source VM
|
||||
```
|
||||
|
||||
**Resolution:**
|
||||
1. Verify the VMware credentials have snapshot creation permissions
|
||||
2. Check if a snapshot with the same name already exists on the source VM — remove stale `vjailbreak-*` snapshots
|
||||
3. Ensure the source VM's datastore has sufficient free space for the snapshot delta files
|
||||
|
||||
### Migration Stuck After Snapshot
|
||||
|
||||
If the migration is stuck after taking the snapshot and the source VM remains powered off:
|
||||
|
||||
1. Check v2v helper logs for the last successful phase
|
||||
2. If the Proxy VM became unavailable, the migration will not auto-recover — clean up manually:
|
||||
```bash
|
||||
# Remove the snapshot from vCenter
|
||||
govc snapshot.remove -vm "<source-vm>" "vjailbreak-hotadd-snap"
|
||||
```
|
||||
3. Detach any disks vJailbreak attached to the Proxy VM before retrying
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Dedicate the Proxy VM**: Avoid running other workloads on the Proxy VM during migrations to ensure stable performance
|
||||
2. **Match network placement**: Place the Proxy VM on a network with low latency to the vJailbreak VM for fast NBD transfers
|
||||
3. **Verify before migrating**: Always confirm the Proxy VM shows **Ready** status before starting a migration
|
||||
4. **Monitor disk space**: Snapshot delta files consume datastore space — ensure the source VM's datastore has at least 20% free space
|
||||
5. **Use the recommended OVA**: The pre-built OVA is tested and configured correctly; custom VMs require manual validation of all prerequisites
|
||||
6. **Rotate SSH keys**: Use a dedicated key pair for vJailbreak and rotate it periodically
|
||||
+247
@@ -0,0 +1,247 @@
|
||||
---
|
||||
title: "Migrating RDM Disk"
|
||||
description: "A guide on how to migrate a Virtual Machine with RDM disks using the vjailbreak CLI."
|
||||
---
|
||||
|
||||
|
||||
RDM disks are primarily used for clustered Windows machines.
|
||||
|
||||
This guide walks you through the steps required to migrate a VM with **RDM (Raw Device Mapping) disks** using the CLI.
|
||||
|
||||
RDM disk migration is only supported for **PCD version >= July 2025 (2025.7)** and is **not supported for OpenStack**.
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before you begin, ensure the following:
|
||||
|
||||
1. **RDM disk is attached** to the Windows machine.
|
||||
2. **vjailbreak** is deployed in your cluster.
|
||||
3. **PCD Requirements**:
|
||||
- Minimum version: **July 2025 (2025.7)**.
|
||||
- For multipath support (connecting to SAN array): **October 2025 (2025.10)** - includes patched libvirt and QEMU packages.
|
||||
- **Volume type must have multi-attach support enabled** in OpenStack.
|
||||
4. All required fields (like `cinderBackendPool` and `volumeType`) are available from your `OpenstackCreds`.
|
||||
5. Source Details are added on RDM VMs in VMware described [here](#on-vmware)
|
||||
6. Storage array configured in PCD is same as the one configured in VMware. Usually SAN arrays have logical pools/isolation, that must be same as well.
|
||||
|
||||
You can fetch `cinderBackendPool` and `volumeType` values using:
|
||||
|
||||
By describing the OpenStack credentials in vjailbreak:
|
||||
|
||||
```bash
|
||||
kubectl describe openstackcreds <openstackcredsname> -n migration-system
|
||||
```
|
||||
|
||||
After describing the OpenStack credentials, look for `volumeTypes` and `volumeBackend`. Gather the `volumeTypes` and `volumeBackend` values that need to be patched as mentioned in [step 4 of Migration steps](#4-patch-rdm-disk-with-the-required-fields).
|
||||
|
||||
**Alternatively** you can also gather details using openstack cli
|
||||
|
||||
```bash
|
||||
openstack volume backend pool list
|
||||
openstack volume type list
|
||||
```
|
||||
|
||||
Please refer to the following documents for commands to fetch volume backend pool and volume type lists:
|
||||
|
||||
opnestack cli version >= 6.2.1
|
||||
|
||||
- [Volume Type List](https://docs.openstack.org/python-openstackclient/queens/cli/command-objects/volume-type.html#volume-type-list)
|
||||
- [Volume Backend Pool List](https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/volume-backend.html#volume-backend-pool-list)
|
||||
|
||||
## RDM Validation settings
|
||||
|
||||
In vjailbreak setting configmap we have a setting called `VALIDATE_RDM_OWNER_VMS` whose default value is `true`.
|
||||
|
||||
This setting manadates all VM linked to RDM disk must be migrated in a single migration plan, to disable it set `VALIDATE_RDM_OWNER_VMS` to false
|
||||
|
||||
## On VMware
|
||||
|
||||
Perform the following steps on each VM from the cluster you are planning to migrate.
|
||||
|
||||
- Add the following annotation to the VMware Notes field for the VM:
|
||||
|
||||
```
|
||||
VJB_RDM:{Name of Hardisk}:volumeRef:source-name=abac111
|
||||
```
|
||||
|
||||
- VJB_RDM – Key prefix indicating this entry is an RDM (Raw Device Mapping) LUN reference.
|
||||
- {Name of Hardisk} - Name of the RDM disk attached to the VM. Replace this placeholder with the actual disk name.
|
||||
Disk Name is case sensitive.
|
||||
- volumeRef – Denotes the reference section for the volume configuration.
|
||||
source-name=abac111 – Specifies the LUN reference.
|
||||
The key can be either source-id or source-name.
|
||||
|
||||
The value is the LUN identifier (ID or Name) used to map the disk.
|
||||
To obtain the source details ie `source-id`, `source-name`, you can run the following command against the SAN Array:
|
||||
|
||||
```bash
|
||||
openstack block storage volume manageable list <Cinder backend pool name> --os-volume-api-version 3.8
|
||||
```
|
||||
|
||||
**Note: Not all SAN arrays are supported by the OpenStack block storage client, in such cases above command gives an empty output. If you cannot find your SAN array reference from the block storage client, contact your storage administrator to get the LUN reference by accessing the storage provider's interface.**
|
||||
|
||||
RDM disk migration has been tested with two storage arrays:
|
||||
|
||||
1. HPE Primera
|
||||
2. NetApp ONTAP
|
||||
|
||||
The `manageable list` command is only supported on HPE Primera.
|
||||
|
||||
---
|
||||
|
||||
## Migration Steps
|
||||
|
||||
### 1. Verify RDM Disk Resource
|
||||
|
||||
Check if the **RDM disk resource** is created in Kubernetes:
|
||||
|
||||
```bash
|
||||
kubectl get rdmdisk <vml-id> -n migration-system
|
||||
```
|
||||
|
||||
Ensure the added annotations `source-name` or `source-id` are reflected in the vjailbreak RDM disk custom resource. Use the VML ID of the RDM disk from VMware.
|
||||
|
||||
If source details are not correct, edit the Notes section of VMware VM for correct value and wait for reconcilation ( few minutes ), to get source details updated.
|
||||
|
||||
### 2. Ensure RDM disk reference is correctly populated in vmwaremachine
|
||||
|
||||
For each VM's to be migrated, list vm details on vjailbreak using below command:
|
||||
|
||||
```bash
|
||||
kubectl describe vmwaremachine <vm-name> -n migration-system
|
||||
```
|
||||
|
||||
Ensure vml id of all RDM disks to be migrated appear in the vmwaremachine custom resource.
|
||||
|
||||
### 3. Detach the RDM Disk and Power Off the VM in VMware
|
||||
|
||||
Since VMware does not allow snapshots of a VM with attached RDM disks, you must:
|
||||
|
||||
- **Power off** the VM to be migrated.
|
||||
- **Detach the RDM disk** from the VM (steps are mentioned below).
|
||||
|
||||
Optional: Once the RDM disk is detached,you can list the vmwaremachine custom resource and ensure the VML ID of all RDM disks to be migrated appear in rdmDisk section of vmwaremachine custom resource in vjailbreak.
|
||||
|
||||
```bash
|
||||
kubectl describe vmwaremachine <vm-name> -n migration-system
|
||||
```
|
||||
|
||||
**Note:** Once the RDM disk is detached, the `source-name` or `source-id` should not change, and the VMs that own the RDM disk should not change. If you need to detach the RDM disk from the VM and remove all RDM references from the VMs, you must handle it manually
|
||||
<br>
|
||||
|
||||
Delete the `vmwaremachine` and `rdmdisk` custom resources on vjailbreak. After deletion wait for the configured reconciliation time, and re ensure that deleted resources are recreated by vjailbreak.
|
||||
|
||||
**Commands to delete VMware machine and RDM disk:**
|
||||
|
||||
```bash
|
||||
kubectl delete vmwaremachine <vm-name> -n migration-system
|
||||
```
|
||||
|
||||
```bash
|
||||
kubectl delete rdmdisk <rdm-vml-id> -n migration-system
|
||||
```
|
||||
|
||||
**Commands to verify VMware machine and RDM disk are recreated**
|
||||
|
||||
```bash
|
||||
kubectl describe vmwaremachine <vm-name> -n migration-system
|
||||
```
|
||||
|
||||
```bash
|
||||
kubectl describe rdmdisk <vml-id> -n migration-system
|
||||
```
|
||||
|
||||
**Steps to detach RDM disks in VMware:**
|
||||
|
||||
For each VM, go to **Edit Settings** and perform following steps. _Note down the details as you might need them in case you have to revert the migration._
|
||||
|
||||
1. Click on the cross icon near the RDM disks, and keep "Delete files from storage" **unchecked**.
|
||||
2. Remove the SCSI controller used by these disks (this will be in Physical sharing mode).
|
||||
|
||||
Note: Only remove the SCSI controller in Physical Sharing mode. Other volumes or non-RDM disks use different controllers (not in Physical Sharing mode), and those must not be deleted.
|
||||
|
||||
|
||||
|
||||
This ensures that the snapshot and migration can proceed without errors.
|
||||
|
||||
### 4. Patch RDM Disk with the Required Fields
|
||||
|
||||
Edit each RDM disk to add `cinderBackendPool` and `volumeType`. Example:
|
||||
|
||||
```bash
|
||||
kubectl patch rdmdisk <name_of_rdmdisk_resource> -n migration-system -p '{"spec":{"openstackVolumeRef":{"cinderBackendPool":"backendpool_name","volumeType":"volume_type"}}}' --type=merge
|
||||
```
|
||||
|
||||
The volume type specified here must match the configuration the RDM disk volume has on the SAN array. Example: if the volume has de-duplication and compression enabled, the specified volume type on OpenStack side must have these settings enabled.
|
||||
|
||||
### 5. Create Migration Plan
|
||||
|
||||
Create a migration plan using the CLI.
|
||||
Follow the detailed CLI steps here:
|
||||
|
||||
[Migrating Using CLI and Kubectl](https://platform9.github.io/vjailbreak/guides/cli-api/migrating_using_cli_and_kubectl/)
|
||||
|
||||
Note:
|
||||
|
||||
- While creating migration plan , make sure actual VM name is passed in `spec.virtualMachines` of migrationplan and not vm custom resource name.
|
||||
- Migration plan `spec.migrationStrategy.type` should be cold - RDM disk can only be migrated with cold migrationStrategy
|
||||
|
||||
### 6. Wait for Disk to Become Available
|
||||
|
||||
Confirm that the rdm disk is in **Available** state:
|
||||
|
||||
```bash
|
||||
kubectl get rdmdisk <disk-id> -n migration-system -o yaml
|
||||
```
|
||||
|
||||
Look for:
|
||||
|
||||
```yaml
|
||||
status:
|
||||
phase: Available
|
||||
```
|
||||
|
||||
### 7. Ensure All the VMs in Cluster are Migrated
|
||||
|
||||
1. Check that the RDM disk is available as a volume in PCD or OpenStack.
|
||||
|
||||
2. Ensure all VMs in the cluster are migrated.
|
||||
|
||||
### 8. Retrying failed migrations
|
||||
|
||||
If VM migrations fails, but RDM disks have been successfully managed by Cinder [Step 6](#6-wait-for-disk-to-become-available), migration can be retried.
|
||||
|
||||
### Rollback Plan - If Migration Fails
|
||||
|
||||
### ⚠️ Caution:
|
||||
|
||||
Once an RDM disk is managed in OpenStack or PCD, do not delete the corresponding volume from PCD/OpenStack during a rollback.
|
||||
Deleting the volume will also remove the associated LUN reference from the storage array, resulting in irreversible data loss.
|
||||
|
||||
To unmanage an RDM disk safely, use the following command instead of deleting it directly:
|
||||
|
||||
`openstack volume delete <volume-id> --remote`
|
||||
|
||||
1. Delete VMs created in PCD or OpenStack.
|
||||
2. Remove the managed volume from OpenStack without deleting it from the SAN array:
|
||||
|
||||
```bash
|
||||
openstack volume delete <volume-id> --remote
|
||||
```
|
||||
|
||||
- [Volume Delete](https://docs.redhat.com/en/documentation/red_hat_openstack_platform/10/html/command-line_interface_reference_guide/openstackclient_subcommand_volume_delete)
|
||||
|
||||
3. Re-attach RDM disk in VMware to powered-off VMs:
|
||||
|
||||
- Add the reference VMDK disks.
|
||||
- Add **New Device > Existing Hard Disk**. This will add the disk as a new hard disk.
|
||||
- Change the controller of this hard disk to **"New SCSI Controller"** which was created in the first step.
|
||||
- For each VM, go to **Edit Settings** and add the SCSI controller for disk and select physical sharing mode.
|
||||
|
||||
Repeat this process for all RDM disks.
|
||||
|
||||
|
||||
|
||||
4. Power on all the VMs on VMware.
|
||||
@@ -0,0 +1,502 @@
|
||||
---
|
||||
title: "Use CLI to Migrate"
|
||||
description: "Learn how to automate the migration of Virtual Machines from VMware to PCD using vJailbreak"
|
||||
---
|
||||
vJailbreak comprises multiple Kubernetes Controllers which work on Custom Resources (CRs). When we perform the migrations through the UI, the UI itself takes care of creating these CRs for us, hence paving the way for migration to happen. In this tutorial, we will understand how we can migrate a VM using vJailbreak via CLI.
|
||||
|
||||
|
||||
## Flow of information and resource creation
|
||||
|
||||
Before moving to the action, let’s understand the various resources that will be created to perform a migration, and how they are related to each other.
|
||||
|
||||
|
||||
**Note**: In the diagram above, the specification/configuration flows towards the arrow, and the status travels backwards (from `v2v-helper` Pod up till `MigrationPlan`).
|
||||
|
||||
|
||||
### Glossary
|
||||
|
||||
Let’s get familiar with the resources mentioned in the diagram above. These resources are used by vJailbreak to perform the migration.
|
||||
|
||||
|
||||
|
||||
* **NetworkMapping**: Defines how source VMware networks map to destination OpenStack networks. Required for configuring network interfaces for VM's during migration.
|
||||
* **StorageMapping**: Maps source VMware datastores to OpenStack storage backends.
|
||||
* **MigrationTemplate**: It defines a reusable set of configurations for migrating virtual machines (VM's) from VMware to OpenStack.
|
||||
* **MigrationPlan**: MigrationPlan contains the VM's to be migrated, provides reference to migration template which needs to be followed, and also specifies the way VM's have to be migrated. A migration plan can be used for migrating multiple VM's in batches.
|
||||
* **Migration**: For each VM, there is an individual migration custom resource, which provides reference to the migration plan to be followed and the pod which is going to execute the migration. Migration custom resource is maintained by the vJailbreak controller itself.
|
||||
* **Job**: With migration custom resource in place, the vJailbreak controller creates a Kubernetes Job, which will in turn create the v2v-helper pod to execute migration for the particular VM mentioned in the Migration custom resource.
|
||||
* **v2v-helper pods**: Based on the definition of the job created by vJailbreak controller, kubernetes creates a pod to perform the actual VM migration. These pods are temporary workloads that run the helper logic and handle all the migration steps such as image conversion, driver injection, guest customization, transfer, and creation of OpenStack resources.
|
||||
|
||||
**Note**: `NetworkMapping`, `StorageMapping`, `MigrationTemplate`, `MigrationPlan`, and `Migration` are Custom Resources.
|
||||
|
||||
Now that we have a basic understanding of the resources that will be useful during our journey, let’s start on the migration part.
|
||||
|
||||
|
||||
## How to migrate a VM using CLI or kubectl?
|
||||
|
||||
|
||||
### What are we going to do?
|
||||
|
||||
First, we will gather some configuration details. We will use those pieces of configuration details together to create some custom resources, which will be then picked by the Migration Controller, and the migration will take place accordingly. While migration takes place, we will check various resources to monitor the progress of the migration.
|
||||
|
||||
* [Gather Information](#gather-information)
|
||||
* [Gather the credentials to VMware vCenter and OpenStack](#gather-the-credentials-to-vmware-vcenter-and-openstack)
|
||||
* [Gather the details of the VM to be migrated](#gather-the-details-of-the-vm-to-be-migrated)
|
||||
* [Gather the details of OpenStack networks and volumeTypes](#gather-the-details-of-openstack-networks-and-volumetypes)
|
||||
* [Creation of Kubernetes resources](#creation-of-kubernetes-resources)
|
||||
* [Create the StorageMapping custom resource](#create-the-storagemapping-custom-resource)
|
||||
* [Create the NetworkMapping custom resource](#create-the-networkmapping-custom-resource)
|
||||
* [(Optional) Explicitly select the target OpenStack flavor](#optional-explicitly-select-the-target-openstack-flavor)
|
||||
* [Create the MigrationTemplate custom resource](#create-the-migrationtemplate-custom-resource)
|
||||
* [Create the MigrationPlan custom resource](#create-the-migrationplan-custom-resource)
|
||||
* [Monitor the progress](#monitor-the-progress)
|
||||
* [Checking Migration (custom resource)](#migration-custom-resource)
|
||||
* [Checking Migration Job](#migration-job)
|
||||
* [Checking v2v-helper pod](#v2v-helper-pod)
|
||||
|
||||
|
||||
### Assumptions
|
||||
|
||||
Before we start, ensure the following prerequisites are fulfilled:
|
||||
|
||||
* vJailbreak is installed and configured properly
|
||||
* VMware vCenter credentials and OpenStack credentials are already set up
|
||||
* User is familiar with Kubernetes and has access to the vJailbreak VM
|
||||
* All the resources will be created in the same namespace
|
||||
|
||||
Ensure that you follow the steps in sequence to gather information and create respective Kubernetes objects in sequence to initiate migration for a VM from VMware to PCD.
|
||||
|
||||
### Gather Information
|
||||
|
||||
For creating the resources, we will need some values to put into the YAML manifests. Let’s gather those values first.
|
||||
|
||||
|
||||
#### Gather the credentials to VMware vCenter and OpenStack
|
||||
|
||||
Check the resource name for the VMware vCenter credentials using the following command:
|
||||
|
||||
```
|
||||
kubectl get vmwarecreds -n <namespace>
|
||||
```
|
||||
|
||||
**Note**: The default namespace for vJailbreak ecosystem is `migration-system`.
|
||||
|
||||
Copy the name of the `VMwareCreds` resource that refers to the vCenter hosting the VM you want to migrate. This will be used when creating the MigrationTemplate. For example, if following is the output of the above command:
|
||||
|
||||
```
|
||||
$ kubectl get vmwarecreds -n migration-system
|
||||
NAME STATUS
|
||||
vcenter-a Succeeded
|
||||
```
|
||||
|
||||
Then, the name of the `VMwareCreds` would be `vcenter-a`.
|
||||
|
||||
Similarly, check the resource name for the OpenStack credentials using the following command:
|
||||
|
||||
```
|
||||
kubectl get openstackcreds -n <namespace>
|
||||
```
|
||||
|
||||
|
||||
Copy the name of the `OpenstackCreds` resource that refers to the OpenStack where you want to migrate the VM. This will also be used when creating the MigrationTemplate.
|
||||
|
||||
For example, if following is the output of the above command:
|
||||
|
||||
```
|
||||
$ kubectl get openstackcreds -n migration-system
|
||||
NAME STATUS
|
||||
openstack-a Succeeded
|
||||
```
|
||||
|
||||
Then the name of the `OpenStackcreds` would be `openstack-a`.
|
||||
|
||||
|
||||
#### Gather the details of the VM to be migrated
|
||||
|
||||
Get the details of the VM using `VMwareMachine` resource and details are correct:
|
||||
```
|
||||
kubectl get vmwaremachine -n <namespace> <vm-name> -o yaml
|
||||
```
|
||||
|
||||
From the YAML, note down the following:
|
||||
* VM's name using `spec.vms.name`
|
||||
* Get the datastores under `spec.vms.datastores`. This will be used for storage mapping.
|
||||
* Get the networks under `spec.vms.networks`. This will be used for network mapping.
|
||||
* (Optional) Get the Operating System type under `spec.vms.osFamily`. The reason for keeping it optional is that vJailbreak can auto-detect the OS most of the time, if the VM is turned on in VMware. For cold migration or migration of a VM that is in powered off state, this field will be required.
|
||||
* (Optional) Note the VM's `spec.vms.cpu` and `spec.vms.memory`. If you don't explicitly choose a target flavor (see [Explicitly select the target OpenStack flavor](#optional-explicitly-select-the-target-openstack-flavor) below), vJailbreak uses these values to auto-select the closest matching OpenStack flavor at migration time.
|
||||
|
||||
For example, if following is the output of the above command:
|
||||
|
||||
```
|
||||
$ kubectl get vmwaremachines -n migration-system vm-1 -o yaml
|
||||
|
||||
apiVersion: vjailbreak.k8s.pf9.io/v1alpha1
|
||||
kind: VmwareMachine
|
||||
metadata:
|
||||
name: vm-1
|
||||
namespace: migration-system
|
||||
creationTimestamp: "2025-05-27T09:27:34Z"
|
||||
generation: 1
|
||||
labels:
|
||||
pcd-vm-openstack-a: d3f3d5c7-f6d8-410e-bb9f-a7afe4j8nhg
|
||||
vmwarecreds.k8s.pf9.io-vcenter-a: "true"
|
||||
spec:
|
||||
vms:
|
||||
clusterName: cluster-1
|
||||
esxiName: esxi-1
|
||||
ipAddress: <ip-of-the-vm>
|
||||
cpu: 1
|
||||
memory: 4096
|
||||
name: vm-1
|
||||
osFamily: linuxGuest
|
||||
vmState: running
|
||||
datastores:
|
||||
- datastore-1
|
||||
- datastore-2
|
||||
disks:
|
||||
- Hard disk 1
|
||||
- Hard disk 2
|
||||
networks:
|
||||
- network-1
|
||||
- network-2
|
||||
```
|
||||
|
||||
Then:
|
||||
* The name of the datastores would be: `datastore-1` and `datastore-2`
|
||||
* The name of the networks would be: `network-1` and `network-2`
|
||||
* The OS family would be: `linuxGuest`
|
||||
|
||||
After gathering the information about the source VM’s datastores and networks, we will need to gather the information about the networks and volume types present on the OpenStack, so that we can create proper StorageMapping and NetworkMapping configurations.
|
||||
|
||||
|
||||
#### Gather the details of OpenStack networks and volumeTypes
|
||||
|
||||
Using the name of the OpenstackCreds resource that we recently checked, run the following command to get the configuration:
|
||||
|
||||
```
|
||||
kubectl get openstackcreds -n <namespace> <openstackcreds-resource-name> -o yaml
|
||||
```
|
||||
|
||||
|
||||
From the YAML, note down the following:
|
||||
* List of the networks available on OpenStack at `status.openstack.networks`
|
||||
* List of volume types available on OpenStack at `status.openstack.volumeTypes`
|
||||
|
||||
For example, if following is the output of the above command:
|
||||
|
||||
```
|
||||
$ kubectl get openstackcreds -n migration-system openstack-a -o yaml
|
||||
apiVersion: vjailbreak.k8s.pf9.io/v1alpha1
|
||||
kind: OpenstackCreds
|
||||
metadata:
|
||||
name: openstack-a
|
||||
# …
|
||||
spec:
|
||||
# …
|
||||
status:
|
||||
openstack:
|
||||
networks:
|
||||
- vlan1
|
||||
- vlan2
|
||||
- vlan3
|
||||
volumeTypes:
|
||||
- lvm
|
||||
- lvm-class-2
|
||||
- lvm-class-3
|
||||
|
||||
```
|
||||
|
||||
Then:
|
||||
* VMware networks `network-1` and `network-2` can be translated to OpenStack networks `vlan1`/`vlan2`/`vlan3`
|
||||
* VMware datastores `datastore-1` and `datastore-2` can be translated to OpenStack volume types `lvm`/`lvm-class-2`/`lvm-class-3`
|
||||
|
||||
We will see these translations in action when we create NetworkMapping and StorageMapping resources in the next section, respectively.
|
||||
|
||||
|
||||
### Creation of Kubernetes resources
|
||||
|
||||
Now that we have gathered the information that we required, let’s start creating the Kubernetes resources to initiate the migration.
|
||||
|
||||
|
||||
#### Create the StorageMapping custom resource
|
||||
|
||||
Let’s create the `StorageMapping` custom resource to ensure that virtual disks are placed correctly in the destination environment. Below is how its manifest would look like:
|
||||
|
||||
|
||||
##### Manifest
|
||||
|
||||
In the manifest, we need to provide a mapping between the source datastores that we captured from the `VMwareMachine` (namely `datastore-1` and `datastore-2`), and will map them with the target volume types that we captured from the `OpenstackCreds`.
|
||||
|
||||
```
|
||||
$ cat storage-mapping.yaml
|
||||
apiVersion: vjailbreak.k8s.pf9.io/v1alpha1
|
||||
kind: StorageMapping
|
||||
metadata:
|
||||
name: storagemapping
|
||||
namespace: migration-system
|
||||
spec:
|
||||
storages:
|
||||
- source: datastore-1
|
||||
target: lvm
|
||||
- source: datastore-2
|
||||
target: lvm
|
||||
```
|
||||
|
||||
##### How to apply this configuration?
|
||||
|
||||
```
|
||||
kubectl apply -f storage-mapping.yaml
|
||||
```
|
||||
|
||||
Read more about `StorageMapping` in [the CRDs reference document](https://platform9.github.io/vjailbreak/reference/reference/#datastore-mapping).
|
||||
|
||||
|
||||
#### Create the NetworkMapping custom resource
|
||||
|
||||
Now, let’s create a `NetworkMapping` custom resource to define how networks will be translated from VMware to OpenStack. Below is how its Kubernetes manifest would look like.
|
||||
|
||||
|
||||
##### Manifest
|
||||
|
||||
In the manifest, we need to provide target networks for both the networks that we captured from the VM (namely `network-1` and `network-2`), and will map them with the target networks that we captured from the `OpenstackCreds`.
|
||||
|
||||
```
|
||||
$ cat network-mapping.yaml
|
||||
apiVersion: vjailbreak.k8s.pf9.io/v1alpha1
|
||||
kind: NetworkMapping
|
||||
metadata:
|
||||
name: networkmapping
|
||||
namespace: migration-system
|
||||
spec:
|
||||
networks:
|
||||
- source: network-1
|
||||
target: vlan1
|
||||
- source: network-2
|
||||
target: vlan2
|
||||
```
|
||||
|
||||
##### How to apply this configuration?
|
||||
|
||||
```
|
||||
kubectl apply -f network-mapping.yaml
|
||||
```
|
||||
|
||||
Read more about `NetworkMapping` in [the CRDs reference document](https://platform9.github.io/vjailbreak/reference/reference/#network-mapping).
|
||||
|
||||
|
||||
#### (Optional) Explicitly select the target OpenStack flavor
|
||||
|
||||
By default, vJailbreak picks the target VM's OpenStack flavor automatically: it looks for a flavor whose vCPU and RAM exactly match the source VM, or the next best match if there is no exact match. This "best guess" match is based on size alone, so if your OpenStack environment has multiple flavors with the same vCPU/RAM but different extra specs or tags (for example, different host aggregates, GPU passthrough, or hotplug support), vJailbreak may not pick the one you intended.
|
||||
|
||||
To avoid this, you can explicitly pin a VM to a specific flavor by setting `spec.targetFlavorId` on its `VMwareMachine` custom resource, before creating the `MigrationPlan`.
|
||||
|
||||
First, find the flavor ID you want to use. Using the OpenStack CLI against your target OpenStack/PCD environment, list the available flavors:
|
||||
|
||||
```
|
||||
openstack flavor list
|
||||
```
|
||||
|
||||
This prints each flavor's ID, name, vCPU count, RAM, and disk size, for example:
|
||||
|
||||
```
|
||||
+--------------------------------------+--------------+------+------+-----------+-------+-----------+
|
||||
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
|
||||
+--------------------------------------+--------------+------+------+-----------+-------+-----------+
|
||||
| d2a1e2d0-1111-4a3e-9c3e-abc123456789 | m1.medium.gpu| 8192 | 40 | 0 | 4 | True |
|
||||
| f8b2c3d1-2222-4b4f-8d4f-def456789012 | m1.medium | 8192 | 40 | 0 | 4 | True |
|
||||
+--------------------------------------+--------------+------+------+-----------+-------+-----------+
|
||||
```
|
||||
|
||||
Identify the flavor that matches what you want (by name and/or by inspecting its extra specs/tags with `openstack flavor show <flavor-name-or-id>`), and copy its `ID` column.
|
||||
|
||||
Once you've identified the flavor ID you want (`d2a1e2d0-1111-4a3e-9c3e-abc123456789` in this example), patch the `VMwareMachine` resource for the VM being migrated:
|
||||
|
||||
```
|
||||
kubectl patch vmwaremachine -n migration-system <vm-name> --type merge -p '{"spec":{"targetFlavorId":"d2a1e2d0-1111-4a3e-9c3e-abc123456789"}}'
|
||||
```
|
||||
|
||||
You can confirm it was set correctly with:
|
||||
|
||||
```
|
||||
kubectl get vmwaremachine -n migration-system <vm-name> -o jsonpath='{.spec.targetFlavorId}'
|
||||
```
|
||||
|
||||
**Note**: `targetFlavorId` is read once, when vJailbreak creates the migration ConfigMap for the VM (as part of `MigrationPlan` processing). Set it on the `VMwareMachine` before creating the `MigrationPlan` for that VM. If it is left blank, vJailbreak falls back to the automatic best-match flavor selection described above.
|
||||
|
||||
#### Create the MigrationTemplate custom resource
|
||||
|
||||
Now that we have `StorageMapping` and `NetworkMapping` resources in place, let’s create a `MigrationTemplate`. As the name suggests, `MigrationTemplate` can be created once for a set of `VMwareCreds`, `OpenstackCreds` and the corresponding `NetworkMapping` and `StorageMapping`. This can be reused between various `MigrationPlan` resources.
|
||||
|
||||
|
||||
##### Manifest
|
||||
|
||||
In the `MigrationTemplate`, we need to provide the following details:
|
||||
* Name of the `NetworkMapping` resource
|
||||
* Name of the `StorageMapping` resource
|
||||
* `VMwareCreds` resource name
|
||||
* `OpenstackCreds` resource name
|
||||
* Type of the OS (Optional)
|
||||
|
||||
```
|
||||
$ cat migration-template.yaml
|
||||
apiVersion: vjailbreak.k8s.pf9.io/v1alpha1
|
||||
kind: MigrationTemplate
|
||||
metadata:
|
||||
name: migrationtemplate
|
||||
namespace: migration-system
|
||||
spec:
|
||||
networkMapping: networkmapping
|
||||
storageMapping: storagemapping
|
||||
osFamily: linux # valid values: linux, windows (optional — auto-detected when VM is powered on)
|
||||
source:
|
||||
vmwareRef: vcenter-a
|
||||
destination:
|
||||
openstackRef: openstack-a
|
||||
```
|
||||
|
||||
|
||||
##### How to apply this configuration?
|
||||
|
||||
```
|
||||
kubectl apply -f migration-template.yaml
|
||||
```
|
||||
|
||||
Read more about `MigrationTemplate` in [the CRDs reference document](https://platform9.github.io/vjailbreak/reference/reference/#migrationtemplate).
|
||||
|
||||
|
||||
#### Create the MigrationPlan custom resource
|
||||
|
||||
After creating the `MigrationTemplate`, we need to create the `MigrationPlan` to configure how migration will be executed. Whether it will be a hot migration, or cold migration? When will the cutover happen? Will the cutover happen automatically or manually? etc. Let’s create a `MigrationPlan` resource.
|
||||
|
||||
|
||||
##### Manifest
|
||||
|
||||
In the manifest, we will provide the name of the `MigrationTemplate` to be used, and various different configurations related to migration execution.
|
||||
|
||||
```
|
||||
$ cat migration-plan.yaml
|
||||
apiVersion: vjailbreak.k8s.pf9.io/v1alpha1
|
||||
kind: MigrationPlan
|
||||
metadata:
|
||||
name: migrationplan
|
||||
namespace: migration-system
|
||||
spec:
|
||||
migrationTemplate: migrationtemplate
|
||||
migrationStrategy:
|
||||
type: hot
|
||||
adminInitiatedCutOver: false
|
||||
performHealthChecks: false
|
||||
healthCheckPort: "443"
|
||||
virtualMachines:
|
||||
- - vm-1
|
||||
```
|
||||
|
||||
To know more about all the supported fields for advanced use-cases, refer to the [MigrationPlan section of the CRD reference document](https://platform9.github.io/vjailbreak/reference/reference/#migrationplan).
|
||||
|
||||
##### Optional MigrationPlan Fields
|
||||
|
||||
The example above shows the minimum required fields. The following optional fields are also supported:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
migrationTemplate: migrationtemplate
|
||||
|
||||
# Retry the migration automatically if it fails
|
||||
retry: false
|
||||
|
||||
# Shell script executed on first boot of the destination VM
|
||||
firstBootScript: |
|
||||
echo "Add your startup script here!"
|
||||
|
||||
# Schedule data copy and cutover windows (RFC 3339 datetime)
|
||||
migrationStrategy:
|
||||
type: hot
|
||||
dataCopyStart: "2024-06-01T02:00:00Z" # when to start copying data
|
||||
vmCutoverStart: "2024-06-01T04:00:00Z" # start of cutover window
|
||||
vmCutoverEnd: "2024-06-01T05:00:00Z" # end of cutover window
|
||||
adminInitiatedCutOver: false
|
||||
performHealthChecks: false
|
||||
healthCheckPort: "443"
|
||||
|
||||
# Post-migration actions on the source VM in VMware
|
||||
postMigrationAction:
|
||||
renameVm: true
|
||||
suffix: "_migrated_to_pcd" # appended to source VM name
|
||||
moveToFolder: true
|
||||
folderName: "migrated" # VMware folder to move source VM into
|
||||
|
||||
# Advanced: override volume types, networks, or ports per VM
|
||||
advancedOptions:
|
||||
granularVolumeTypes:
|
||||
- lvm
|
||||
granularNetworks:
|
||||
- vlan1
|
||||
granularPorts:
|
||||
- "port-uuid-1"
|
||||
|
||||
virtualMachines:
|
||||
- - vm-1
|
||||
```
|
||||
|
||||
##### How to apply this configuration?
|
||||
|
||||
|
||||
```
|
||||
kubectl apply -f migration-plan.yaml
|
||||
```
|
||||
|
||||
Now that we have created all the required resources, let’s see what are the additional resources being created in the background, how do they interconnect, how to find out where the migration of a particular VM is happening, and how to check its progress.
|
||||
|
||||
|
||||
### Monitor the progress
|
||||
|
||||
|
||||
#### Migration (custom resource)
|
||||
|
||||
Whenever a `MigrationPlan` is created, vJailbreak controller creates a `Migration` custom resource for individual VM's mentioned in the `MigrationPlan`.
|
||||
|
||||
|
||||
##### Check the Migration custom resource
|
||||
|
||||
Following the standard naming conventions used by vJailbreak, the `Migration` custom resource has a name like `migration-<vm-name>`. We can confirm if the `MigrationPlan` and VM name are correct or not. To check the specifications of a migration custom resource, run the following command:
|
||||
|
||||
|
||||
```
|
||||
kubectl get migration -n <namespace> migration-<vm-name> -o yaml
|
||||
```
|
||||
|
||||
* MigrationPlan will be available under: `metadata.labels.migrationplan` or `spec.migrationPlan`
|
||||
* VM’s name will be placed under: `spec.vmName`
|
||||
* Once sure that the migration resource is related to the VM we want to track the migration of, check the pod prefix under: `spec.podRef`
|
||||
|
||||
|
||||
#### Migration Job
|
||||
|
||||
Migration Job is a Kubernetes Job responsible for migrating one VM from VMware to OpenStack. It runs a pod which performs all tasks required to migrate a single VM including disk extraction, conversion, transfer, and VM creation in the target OpenStack environment. These jobs are created dynamically and are not declared by the user.
|
||||
|
||||
|
||||
##### Check the Migration Job
|
||||
|
||||
|
||||
* Following the standard naming conventions followed by vJailbreak, the job has a name like `v2v-helper-<vm-name>`.
|
||||
* We can check the status of the job under the `status` section.
|
||||
|
||||
|
||||
#### v2v-helper pod
|
||||
|
||||
v2v-helper pod is the Kubernetes Pod created by Migration Job. It is the runtime unit that performs the actual VM migration, including disk extraction, transformation, and transfer from vSphere to OpenStack. It is the execution engine for migrating one VM. It runs the v2v-helper utility to perform these actions.
|
||||
|
||||
|
||||
##### Check the v2v-helper pod logs
|
||||
|
||||
|
||||
|
||||
* After getting the pod name from the migration custom resource, you can check the logs of the pod using the following command:
|
||||
|
||||
```
|
||||
kubectl logs -n <namespace> <pod-name>
|
||||
```
|
||||
|
||||
* To tail the live logs, we can use the `-f` flag.
|
||||
|
||||
This way, we can automate the migration for n numbers of Virtual Machines, from VMware to OpenStack, using vJailbreak via kubectl.
|
||||
@@ -0,0 +1,87 @@
|
||||
---
|
||||
title: Cluster Conversion
|
||||
description: Configuration and steps to perform cluster conversion
|
||||
---
|
||||
|
||||
The following outlines the steps to use the vJailbreak RollingConversion feature, which is exclusively available and compatible with Platform9 Private Cloud Director (PCD).
|
||||
|
||||
## Pre-migration checks
|
||||
|
||||
Before starting the RollingConversion process, ensure the following checks are completed:
|
||||
|
||||
1. Ensure vCenter setup is available
|
||||
* vCenter credentials must possess sufficient privileges to isolate ESXi hosts, place them into maintenance mode, and subsequently remove them from the inventory. These privileges are supplementary to existing permissions. The precise set of required permissions will be communicated imminently.
|
||||
2. Ensure PCD (Platform9 Private Cloud Director) setup is available and properly configured.
|
||||
* Ensure the ClusterBlueprint is configured.
|
||||
** Within the Rolling Conversion form in vJailbreak UI, it is necessary to specify the desired network configuration to be implemented on the host subsequent to its conversion and onboarding to Platform Cloud Director (PCD).
|
||||
* Verify network setup on PCD aligns with the ClusterBlueprint specifications.
|
||||
* Make sure one host is already added to accommodate vJailbreak VM and its agents
|
||||
3. Ensure Ubuntu MAAS setup is available and configured
|
||||
* Only Ubuntu 22.04 is currently supported for PCD hosts within the Private Cloud Director (PCD).
|
||||
* Ensure that the appropriate PXE image is configured based on requirements; a standard Ubuntu 22 image is recommended.
|
||||
* It is presumed that the ESX hosts are pre-configured as "Machines" in the "Allocated or Deployed" state within MAAS.
|
||||
* **IMPORTANT**: All ESXi hosts added to MAAS must have IPMI details configured. vJailbreak uses IPMI to control the power state and boot order of the ESXi hosts during the conversion process. Verify the accuracy of the IPMI configuration for all the MAAS machines before starting the rolling conversion.
|
||||
4. Backup current configurations and data related to vCenter.
|
||||
5. Ensure vMotion configured correctly on vCenter
|
||||
* I.e, If an ESX is put in maintenance mode, VMs should be able to move off that ESX
|
||||
6. Make sure that all non-vmotion compatible VMs are migrated to the destination PCD or moved off to a single ESXI
|
||||
* When we put an ESXi in maintenance mode, we expect all the VMs to move off of that ESXi and wait for it to become empty.
|
||||
* Even if a single VM is present on that ESXI, we cannot really re-flash it safely.
|
||||
7. Ensure enough additional hosts on vCenter (Number of hosts will differ on the exact setup configuration)
|
||||
* NOTE: We put the ESX hosts in maintenance mode one by one, so the VMs on these hosts are moved off until the host becomes empty. This host is further converted to PCD host. The extra hosts are required to accommodate the moved off VMs
|
||||
* NOTE: It is not required to have the equal number of extra hosts, ideally just one.
|
||||
8. Check available disk space on target systems within the PCD environment.
|
||||
|
||||
#### List of incompatible configurations for reference
|
||||
* VMs with PCIe passthrough or SR-IOV devices
|
||||
* VMs using local host devices (e.g. USB, CD/DVD)
|
||||
* VMs with RDM disks in physical mode
|
||||
* VMs with Fault Tolerance (FT) enabled
|
||||
* VMs with CPU features not compatible across hosts
|
||||
* VMs without Enhanced vMotion Compatibility (EVC) in mixed-CPU clusters
|
||||
* VMs using host-only or non-shared network/storage
|
||||
* VMs with VMCI or special device interfaces
|
||||
* VMs in suspended state (for live vMotion)
|
||||
* VMs with outdated VMware Tools or hardware version
|
||||
|
||||
## Configuration
|
||||
|
||||
Create VMware and OpenStack/PCD credential with "PCD" configuration only PCD is supported for rolling upgrade
|
||||
|
||||
### MAAS configuration
|
||||
|
||||
* **MAAS URL** - the MAAS system should be reachable
|
||||
* **API Key** additionally the MAAS system should be configured to allow the vJailbreak VM to access it with the key
|
||||
* **OS** the os configuration that vJailbreak would use in MAAS to direct the MAAS to boot the ESXi into PCD hypervisor
|
||||
|
||||
#### Import the ESXi into MAAS
|
||||
|
||||
If you have ESXi already deployed through MAAS, you can skip this step, else you will need to import ESXis into MAAS so that MAAS can recognize them.
|
||||
|
||||
## How cluster conversion works
|
||||
After you submit the rolling conversion form, vJailbreak will take the following actions in sequence.
|
||||
|
||||
1. Verify your creds, especially **openstack-creds** for checking if they are **PCD creds** or not
|
||||
2. Verify Cluster information submitted in the form.
|
||||
3. Prepare a **special cloud-init script** that will run **post conversion** of this host to a ubuntu machine.
|
||||
4. Go through the list of VMs specified in the rolling conversion form
|
||||
5. Formulate and save a **list of ESXis to be converted**.
|
||||
6. Trigger the conversion process of these ESXi sequentially.
|
||||
7. Each conversion process includes following steps
|
||||
1. Put that ESXi in **maintenance mode**
|
||||
2. Wait for all VMs on that ESXi to move off of this ESXi to other hosts **(by DRS/vMotion)**
|
||||
3. Once the ESXi is empty, vJailbreak starts the process of converting it to PCD host
|
||||
1. Fetch list of all available **“Machines”** in MAAS
|
||||
2. Find the correct **“Machine”** for the current ESXi, by checking the **hardwareUUID** received both from vCenter API and MAAS API
|
||||
3. Once Machine is found, we fetch its **IPMI configuration** from MAAS, and use to set this machine **PXE (net) boot**
|
||||
4. **Release** the machine in MaaS
|
||||
5. **Deploy** the machine via MaaS, using the special cloud-init created in earlier steps
|
||||
4. Now vJailbreak waits for MaaS to boot that machine to an **ubuntu image** and run the **cloud-init** that we provided.
|
||||
5. Its polling mechanism checks the list of PCD hosts and verifies the **hardwareUUID** from MaaS with **hostID** from PCD. (HostID is forcefully set to **hardwareUUID** in the cloud-init)
|
||||
6. Once vJailbreak sees the host in PCD in “unauthorised” state, vJailbreak makes API calls to PCD
|
||||
1. To apply the “Host Network Configuration” selected for this host during the “**Rolling Conversion Form”** submission
|
||||
2. To provide hypervisor role to this host, with an input of the **clusterName** used as **Target** in the “**Rolling Conversion Form”**
|
||||
7. Wait for the PCD host to **converge**.
|
||||
8. Mark the ESXi Conversion as **Successful**.
|
||||
8. If at least one ESXi conversion is successful, vJailbreak will start to migrate VMs (from the list in “**Rolling Conversion Form”**) to PCD (to the specified target Cluster)
|
||||
9. RollingConversion is marked successful if all (selected) ESXi are converted and all (selected) VMs are moved to PCD.
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: Add ESXi to MAAS
|
||||
description: Configuration and steps to to add ESXi to MAAS
|
||||
---
|
||||
|
||||
vJailbreak uses MAAS to manage the ESXi hosts and boot them into PCD hypervisor.
|
||||
MAAS has a state machine for each machine that it manages. The machines by default are
|
||||
assumed to be 'empty' and available for deployment. The machines are managed by MAAS by booting them with ephemeral image to discover the hardware.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
**IMPORTANT**: Before adding ESXi hosts to MAAS, ensure that IPMI (Intelligent Platform Management Interface) is configured and accessible for each ESXi host. vJailbreak requires IPMI access to control the power state and boot order of the ESXi hosts during the rolling conversion process. Without proper IPMI configuration, the conversion process will fail.
|
||||
|
||||
Verify the following:
|
||||
* IPMI is enabled on each ESXi host
|
||||
* IPMI credentials (username/password) are available
|
||||
* IPMI interface is network accessible from both the MAAS server and the vJailbreak VM
|
||||
* IPMI power type is supported by MAAS (e.g., `ipmi`, `LAN_2_0`)
|
||||
|
||||
## Adding ESXi to MAAS
|
||||
|
||||
To enlist an ESXi host into MAAS, you will need to add it to MAAS without MAAS rebooting it
|
||||
inadvertently. The process in detail is described [[here](https://maas.io/docs/reference-release-notes-maas-3-1#p-11417-enlist-deployed-machines)].
|
||||
|
||||
This requires you to have a MAAS cli. The MAAS cli can be used to add any machine in the
|
||||
'deployed' state.
|
||||
|
||||
```
|
||||
$ maas $profile machines create deployed=true hostname=mymachine \
|
||||
architecture=amd64 mac_addresses=00:16:3e:df:35:bb power_type=ipmi \
|
||||
power_parameters_power_address=<IPMI_IP> \
|
||||
power_parameters_power_user=<IPMI_USER> \
|
||||
power_parameters_power_pass=<IPMI_PASSWORD>
|
||||
```
|
||||
|
||||
**Note**: Replace `power_type=manual` with appropriate IPMI power type and include IPMI credentials as shown above.
|
||||
@@ -0,0 +1,133 @@
|
||||
---
|
||||
title: AI-Powered Migration Failure Analysis
|
||||
description: Use the built-in AI assistant to diagnose failed migrations and get remediation steps
|
||||
---
|
||||
|
||||
vJailbreak includes an AI analysis feature that inspects failed migration logs, Kubernetes resource conditions, and known failure patterns to identify root causes and suggest fix steps — without manual log triage.
|
||||
|
||||
:::note
|
||||
AI analysis is experimental and requires an Anthropic API key configured in **Settings → AI**.
|
||||
:::
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- vJailbreak v0.4.8 or later
|
||||
- A failed migration (phase: `Failed` or `ValidationFailed`)
|
||||
- An Anthropic API key — get one at [console.anthropic.com](https://console.anthropic.com)
|
||||
|
||||
## Setup
|
||||
|
||||
### 1. Configure the Anthropic API key
|
||||
|
||||
1. Navigate to **Settings → AI** in the vJailbreak UI.
|
||||
2. Enter your Anthropic API key (`sk-ant-...`).
|
||||
3. Click **Save API Keys**.
|
||||
|
||||
The key is stored in a Kubernetes Secret in `migration-system` and never exposed after saving. The AI service restarts automatically to pick up the new key.
|
||||
|
||||
### 2. Verify the AI service is running
|
||||
|
||||
```bash
|
||||
kubectl -n migration-system get pods -l app=vjailbreak-ai
|
||||
```
|
||||
|
||||
The pod should be in `Running` state. If not, check logs:
|
||||
|
||||
```bash
|
||||
kubectl -n migration-system logs -l app=vjailbreak-ai
|
||||
```
|
||||
|
||||
## Using AI Analysis
|
||||
|
||||
### From the migration detail page
|
||||
|
||||
1. Open a failed migration from the **Migrations** list.
|
||||
2. Click the **AI Analysis** tab (marked *Experimental*).
|
||||
3. Click **Analyse with AI**.
|
||||
|
||||
The AI collects:
|
||||
- Migration CR conditions (primary signal)
|
||||
- v2v-helper pod exit code and logs
|
||||
- Controller logs
|
||||
- Credential validation status
|
||||
- MigrationPlan spec and template config
|
||||
|
||||
It then returns a structured result:
|
||||
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| **Root Cause** | One-sentence description of the failure |
|
||||
| **Fix Steps** | Ordered remediation steps (max 5) |
|
||||
| **Confidence** | `high` / `medium` / `low` / `none` |
|
||||
| **Doc References** | Links to relevant documentation |
|
||||
|
||||
### From the migration logs drawer
|
||||
|
||||
In the migration logs drawer, an **AI Analysis** tab appears alongside the **Logs** tab. Click it to run the same analysis without leaving the log view.
|
||||
|
||||
### Follow-up questions
|
||||
|
||||
After the initial analysis, ask follow-up questions in the text field at the bottom. The AI retains the analysis context for the conversation.
|
||||
|
||||
Example questions:
|
||||
- "What does exit code 137 mean and how do I fix it?"
|
||||
- "How do I check if CBT is enabled?"
|
||||
- "Can I retry without changing the VDDK version?"
|
||||
|
||||
### Feedback
|
||||
|
||||
Use the **thumbs up / thumbs down** buttons to rate the analysis. Feedback helps improve future analyses.
|
||||
|
||||
### Opening a GitHub issue
|
||||
|
||||
If the root cause is identified, click **Open GitHub Issue** to pre-fill an issue with the migration conditions and error excerpt. If confidence is `none`, the AI provides a checklist of data to collect before filing the issue.
|
||||
|
||||
## Confidence levels
|
||||
|
||||
| Level | Meaning |
|
||||
|-------|---------|
|
||||
| `high` | Pattern matched exactly; fix is known and confirmed by logs |
|
||||
| `medium` | Phase is clear but exact cause uncertain, or logs are partial |
|
||||
| `low` | Phase identified only; logs missing or too ambiguous |
|
||||
| `none` | Cannot determine phase or cause from available signals |
|
||||
|
||||
When confidence is `low` or `none`, the first fix step is always diagnostic (gather more data before acting).
|
||||
|
||||
## Known patterns the AI detects
|
||||
|
||||
| Symptom | Root cause | Fix |
|
||||
|---------|-----------|-----|
|
||||
| `"exec: already started"` | nbdkit/VDDK process init race or stale socket | Verify VDDK path, clean up and retry |
|
||||
| Pod exit code 137 | OOM kill | Larger VM flavor or reduce concurrent migrations |
|
||||
| Pod exit code 139 | Segfault in virt-v2v / libguestfs | Check VDDK version vs ESXi version compatibility |
|
||||
| `"Failed to connect"` + VMware/ESXi | DNS not resolving for ESXi host | Add ESXi entries to `/etc/hosts` on vJailbreak VM |
|
||||
| `"permission denied"` or `"401"` + OpenStack | Expired or wrong credentials | Revalidate OpenStack credentials |
|
||||
| `"No space left on device"` | Scratch disk too small for VMDK | Expand `/var` or configure larger scratch space |
|
||||
| `"CBT"` / `"Changed Block Tracking"` not enabled | Hot migration prerequisite missing | Enable CBT on source VM in vCenter |
|
||||
| `"VDDK error"` + error code | VDDK library mismatch or license issue | Verify VDDK version matches ESXi; check VDDK path |
|
||||
|
||||
## Troubleshooting the AI feature
|
||||
|
||||
### "Anthropic API key not configured"
|
||||
|
||||
Navigate to **Settings → AI** and save a valid API key.
|
||||
|
||||
### "AI service unavailable"
|
||||
|
||||
```bash
|
||||
kubectl -n migration-system get pods -l app=vjailbreak-ai
|
||||
kubectl -n migration-system logs -l app=vjailbreak-ai --tail=50
|
||||
```
|
||||
|
||||
Check that the `ANTHROPIC_API_KEY` environment variable is populated in the pod — it is injected from the `vjailbreak-ai-secret` Secret.
|
||||
|
||||
### Analysis returns confidence "none"
|
||||
|
||||
The AI could not identify the root cause from available logs. Collect the following before filing an issue:
|
||||
|
||||
- Full debug logs (use the **Download** button in the migration logs drawer)
|
||||
- `journalctl -u libvirtd -n 200` from the vJailbreak VM
|
||||
- ESXi host version and vCenter version
|
||||
- Whether CBT is enabled on the source VM
|
||||
- VDDK library path: `ls -la /home/ubuntu/vmware-vix-disklib-distrib/`
|
||||
- vJailbreak version: `kubectl -n migration-system get deployment migration-controller-manager -o jsonpath='{.spec.template.spec.containers[0].image}'`
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: Build vJailbreak
|
||||
description: How to compile vJailbreak
|
||||
---
|
||||
|
||||
vJailbreak is intended to be run in a Kubernetes environment (k3s) on the appliance VM. In order to build and deploy the Kubernetes components, follow the instructions in `k8s/migration` to build and deploy the custom resources in the cluster.
|
||||
|
||||
:::tip[Did you know?]
|
||||
Manually building vJailbreak is not required for deployment, only development.
|
||||
:::
|
||||
|
||||
In order to build v2v-helper,
|
||||
|
||||
make v2v-helper
|
||||
|
||||
In order to build migration-controller,
|
||||
|
||||
make vjail-controller
|
||||
|
||||
In order to build the UI,
|
||||
|
||||
make ui
|
||||
|
||||
Change the image names in the makefile to push to another repository.
|
||||
@@ -0,0 +1,121 @@
|
||||
---
|
||||
title: Enable KVM for virt-v2v (Nested Virtualization)
|
||||
description: How to enable nested virtualization so virt-v2v inside the v2v-helper pod can use KVM acceleration instead of falling back to slow TCG emulation.
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
vJailbreak runs `virt-v2v` inside a Kubernetes pod (`v2v-helper`) to convert VM disks and inject drivers. By default, `virt-v2v` uses QEMU as its conversion backend. QEMU can run in two modes:
|
||||
|
||||
| Mode | How it works | Performance |
|
||||
|------|--------------|-------------|
|
||||
| **KVM** (hardware-accelerated) | Uses `/dev/kvm` — the host kernel's KVM module | Fast |
|
||||
| **TCG** (software emulation) | Pure software fallback, no `/dev/kvm` required | ~10–20× slower |
|
||||
|
||||
When `/dev/kvm` is not visible inside the pod, QEMU falls back to TCG and logs:
|
||||
|
||||
```
|
||||
qemu-kvm: Could not access KVM kernel module: No such file or directory
|
||||
qemu-kvm: falling back to tcg
|
||||
```
|
||||
|
||||
Conversions still succeed but take significantly longer.
|
||||
|
||||
## How vJailbreak exposes `/dev/kvm`
|
||||
|
||||
The v2v-helper pod already mounts the host `/dev` directory into the pod at `/dev` via a `hostPath` volume. This means **if `/dev/kvm` exists on the vJailbreak VM, it is automatically visible inside the pod** — no additional configuration is required.
|
||||
|
||||
The condition that must be met is that the vJailbreak VM itself has access to KVM, which requires nested virtualization to be enabled at every layer of the stack.
|
||||
|
||||
⚠️ **Caution — this affects all VMs on the compute host, not just vjailbreak.**
|
||||
|
||||
## Enabling Nested Virtualization
|
||||
|
||||
### Step 1 — Enable nested KVM on the compute host
|
||||
On each compute host that will run vjailbreak VMs and agents:
|
||||
|
||||
```
|
||||
cat /sys/module/kvm_intel/parameters/nested # expect Y (or 1)
|
||||
# AMD: cat /sys/module/kvm_amd/parameters/nested
|
||||
```
|
||||
|
||||
If disabled, enable it persistently and reload:
|
||||
|
||||
```
|
||||
# Intel
|
||||
echo "options kvm-intel nested=1" | sudo tee /etc/modprobe.d/kvm-nested.conf
|
||||
# AMD
|
||||
# echo "options kvm-amd nested=1" | sudo tee /etc/modprobe.d/kvm-nested.conf
|
||||
|
||||
sudo modprobe -r kvm_intel && sudo modprobe kvm_intel # or reboot the host
|
||||
```
|
||||
|
||||
### Step 2 — Set the CPU mode in `nova_override.conf`
|
||||
|
||||
`[libvirt]` section of `/opt/pf9/etc/nova/conf.d/nova_override.conf` on each
|
||||
compute host.
|
||||
|
||||
**Recommended — `host-passthrough`** (passes `vmx`/`svm` through automatically):
|
||||
|
||||
```
|
||||
[libvirt]
|
||||
cpu_mode = host-passthrough
|
||||
```
|
||||
|
||||
**Alternative — `host-model`** (must add the flag explicitly; `host-model` does
|
||||
**not** expose `vmx`/`svm` by default):
|
||||
|
||||
```
|
||||
[libvirt]
|
||||
cpu_mode = host-model
|
||||
cpu_model_extra_flags = vmx # use svm on AMD
|
||||
```
|
||||
|
||||
> **Note:** `host-passthrough` ties the VM to a host with a closely matching
|
||||
> CPU, model, and microcode for live migration. For vjailbreak — a
|
||||
> short-lived, migration-tool VM — this is rarely a concern.
|
||||
|
||||
### Step 3 — Apply
|
||||
|
||||
Restart Nova on the compute host, then hard-reboot the vjailbreak VM so it picks
|
||||
up the new CPU definition (a soft reboot is not enough):
|
||||
|
||||
```
|
||||
sudo systemctl restart pf9-ostackhost
|
||||
openstack server reboot --hard <instance-uuid>
|
||||
```
|
||||
|
||||
### Step 4 — Verify
|
||||
|
||||
Inside the vjailbreak VM, confirm the flag is present:
|
||||
|
||||
```
|
||||
grep -E -o 'vmx|svm' /proc/cpuinfo | sort -u # expect vmx (Intel) or svm (AMD)
|
||||
ls /dev/kvm # device node should exist
|
||||
```
|
||||
|
||||
If `virt-v2v` still falls back to TCG (no acceleration), check that
|
||||
`/dev/kvm` is present and that `kvm-ok` (if available) reports acceleration can
|
||||
be used.
|
||||
|
||||
### Pod (automatic)
|
||||
|
||||
No changes are needed. The pod's `/dev` hostPath mount makes `/dev/kvm` visible to the `v2v-helper` container as soon as it exists on the vJailbreak VM.
|
||||
|
||||
## Verifying KVM is in use
|
||||
|
||||
After enabling nested virtualization and restarting a migration, inspect the v2v-helper pod logs. You should **not** see the TCG fallback warning. Instead, look for QEMU initializing with KVM:
|
||||
|
||||
```bash
|
||||
kubectl -n migration-system logs <migration-name>-v2v-helper | grep -i kvm
|
||||
```
|
||||
|
||||
A healthy KVM-accelerated run shows no `falling back to tcg` messages and noticeably faster conversion times.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
| Symptom | Likely cause | Fix |
|
||||
|---------|--------------|-----|
|
||||
| `Could not access KVM kernel module` in logs | `/dev/kvm` missing on vJailbreak VM | Enable nested virt on the outer hypervisor and load the KVM module |
|
||||
| `kvm_intel`/`kvm_amd` module fails to load | Virtualization extensions not exposed by hypervisor | Configure the outer hypervisor to pass through CPU virt flags |
|
||||
| `/dev/kvm` present on VM but not in pod | Unlikely — the hostPath mount covers all of `/dev` | Confirm the pod spec has the `/dev` hostPath volume (default in vJailbreak) |
|
||||
@@ -0,0 +1,204 @@
|
||||
---
|
||||
title: Firstboot Script
|
||||
description: Guide on using firstboot scripts during VM migration
|
||||
---
|
||||
|
||||
|
||||
## Overview
|
||||
The Firstboot Script feature allows users to run custom scripts automatically on virtual machines (VMs) immediately after they are migrated to Platform9 Cloud Director (PCD) or OpenStack environments. This capability is essential for automating post-migration configurations, installations, and other setup tasks that need to be performed on the VM upon its first boot.
|
||||
|
||||
Following are some use cases for Firstboot Scripts:
|
||||
1. Installing or updating required software
|
||||
2. Removing VMware-specific tools or drivers
|
||||
3. Applying system or network configuration
|
||||
4. Running environment-specific initialization tasks
|
||||
5. Executing multiple setup steps sequentially after migration
|
||||
|
||||
The feature supports **multiple script blocks**, **OS-specific targeting**, and **independent execution** of user-provided scripts.
|
||||
|
||||
|
||||
### Allowed Script Formats
|
||||
|
||||
User-provided script content depends on the guest operating system.
|
||||
|
||||
1. **WindowsGuests**: `Powershell` (.ps1)
|
||||
2. **LinuxGuests**: `sh`, `bash` (.sh)
|
||||
|
||||
---
|
||||
|
||||
## Multiple Script Blocks
|
||||
|
||||
You can include **multiple script blocks** in a single migration plan.
|
||||
Separate each script block using the delimiter:
|
||||
|
||||
```
|
||||
### NEXT SCRIPT ###
|
||||
```
|
||||
|
||||
**Example:**
|
||||
|
||||
```text
|
||||
// WINDOWS-SCRIPT:
|
||||
Write-Host "Running Windows script part 1"
|
||||
|
||||
### NEXT SCRIPT ###
|
||||
|
||||
// WINDOWS-SCRIPT:
|
||||
Write-Host "Script 2 failing intentionally"
|
||||
throw "Failure"
|
||||
|
||||
### NEXT SCRIPT ###
|
||||
|
||||
// WINDOWS-SCRIPT:
|
||||
Write-Host "Script 3 still runs"
|
||||
```
|
||||
|
||||
Each block runs independently. If one script block fails, **later blocks will still execute**.
|
||||
|
||||
|
||||
### Execution Rules
|
||||
|
||||
| Script Tag | Execution Behavior |
|
||||
|------------------|-------------------------------------|
|
||||
| `WINDOWS-SCRIPT:`| Runs only on Windows VMs |
|
||||
| `LINUX-SCRIPT:` | Runs only on Linux VMs |
|
||||
| No tag | Runs on all VMs |
|
||||
|
||||
> **For migration plans containing both Windows and Linux VMs, OS tags are strongly recommended.**
|
||||
|
||||
---
|
||||
|
||||
## Adding a Firstboot Script in the Migration Form
|
||||
|
||||
To configure a post-migration firstboot script:
|
||||
|
||||
1. Open the **Migration Form**
|
||||
2. Navigate to the **Migration Options** section
|
||||
3. Enable **Enable Script** under **Post Migration Script**
|
||||
4. Paste the script content into the script field
|
||||
5. Separate multiple scripts using `### NEXT SCRIPT ###`
|
||||
6. Use OS tags if the migration plan includes different operating systems
|
||||
7. Start the migration
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
> **Note:**
|
||||
> Untagged script blocks run on all selected VMs.
|
||||
|
||||
---
|
||||
|
||||
## How Firstboot Scripts Work
|
||||
|
||||
### End-to-End Execution Flow
|
||||
|
||||
1. The user enables **Post Migration Script** in the migration form.
|
||||
2. The script content is stored in the migration plan as `firstBootScript`.
|
||||
3. The migration controller generates a **per-VM ConfigMap** containing the script.
|
||||
4. The ConfigMap is mounted into the **v2v-helper pod** at `/home/fedora/scripts`.
|
||||
5. During conversion, the helper reads the script and splits it into blocks using `### NEXT SCRIPT ###`.
|
||||
6. Script blocks are filtered based on OS tags.
|
||||
7. The system prepares OS-specific execution:
|
||||
|
||||
| OS | Execution Model |
|
||||
|---------|-----------------|
|
||||
| Linux | Scripts are embedded into a generated wrapper |
|
||||
| Windows | Scripts are converted into PowerShell parts and executed through a scheduler |
|
||||
|
||||
8. When the migrated VM boots for the first time, the prepared scripts execute automatically but needs multiple reboots to complete.
|
||||
|
||||
:::caution[Not available for LDM system volumes]
|
||||
As step 5 shows, firstboot scripts are prepared **during conversion**. Windows VMs
|
||||
whose system volume is on a dynamic disk (LDM) skip conversion, so the Post
|
||||
Migration Script is not installed and will not run. Anything it would have done
|
||||
must be performed manually inside the guest. See
|
||||
[Windows Dynamic Disk (LDM) Migration](../windows-ldm-migration/).
|
||||
:::
|
||||
|
||||
|
||||
## Linux Execution Model
|
||||
|
||||
For **Linux guests**, applicable script blocks are combined into a generated wrapper script.
|
||||
|
||||
The wrapper:
|
||||
- Executes each user script block using Bash
|
||||
- Continues execution even if one block fails
|
||||
- Logs warnings when failures occur
|
||||
|
||||
---
|
||||
|
||||
## Windows Execution Model
|
||||
|
||||
For **Windows guests**, applicable script blocks are converted into **PowerShell script parts**.
|
||||
|
||||
Example generated scripts:
|
||||
```
|
||||
user_firstboot_part_001.ps1
|
||||
user_firstboot_part_002.ps1
|
||||
```
|
||||
|
||||
These scripts are executed using a **Windows Firstboot Scheduler**.
|
||||
|
||||
---
|
||||
|
||||
## Windows Firstboot Scheduler
|
||||
|
||||
The **Windows Firstboot Scheduler** orchestrates execution of built-in and user-provided scripts.
|
||||
It ensures scripts run safely and continue even if reboots occur.
|
||||
|
||||
### Scheduler Responsibilities
|
||||
The scheduler:
|
||||
- Executes scripts sequentially
|
||||
- Tracks execution progress
|
||||
- Survives system reboot
|
||||
- Retries failed scripts
|
||||
- Continues later scripts even if earlier user scripts fail
|
||||
|
||||
### Scheduler Files
|
||||
|
||||
| File | Purpose |
|
||||
|-------------------------------------------|----------------------------------|
|
||||
| `C:\firstboot\0-Firstboot-Scheduler.ps1` | Main scheduler script |
|
||||
| `C:\firstboot\Firstboot-Scheduler.log` | Scheduler execution log |
|
||||
| `C:\firstboot\Firstboot-Scheduler_init.log`| Scheduler initialization log |
|
||||
| `C:\firstboot\Firstboot-Scheduler.state` | Execution state tracking |
|
||||
| `C:\firstboot\scripts.json` | Script metadata |
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Windows Guests
|
||||
Primary troubleshooting locations:
|
||||
|
||||
| File | Purpose |
|
||||
|-------------------------------------------|--------------------------------------|
|
||||
| `C:\firstboot\Firstboot-Scheduler.log` | Scheduler execution logs |
|
||||
| `C:\firstboot\Firstboot-Scheduler_init.log`| Scheduler initialization logs |
|
||||
| `C:\firstboot\Firstboot-Scheduler.state` | Scheduler execution state |
|
||||
| `C:\firstboot\scripts.json` | Script metadata |
|
||||
|
||||
You may also check the guestfs log:
|
||||
|
||||
```
|
||||
C:\Program Files\Guestfs\Firstboot\log.txt
|
||||
```
|
||||
|
||||
This log confirms that the injected firstboot mechanism started successfully.
|
||||
|
||||
### Linux Guests
|
||||
Check the firstboot execution log with elevated privileges:
|
||||
|
||||
```
|
||||
/root/virt-sysprep-firstboot.log
|
||||
```
|
||||
|
||||
This log contains:
|
||||
- Output from each script block
|
||||
- Errors encountered during execution
|
||||
- Warnings for failed script blocks
|
||||
|
||||
## Link to Readily Available Firstboot Scripts
|
||||
1. [Windows VMware tools Removal Script](https://github.com/platform9/vjailbreak/blob/main/scripts/firstboot/windows/vmware-tools-deletion.bat) - A script to remove VMware tools/Drivers from Windows VMs
|
||||
2. [VMware Residual Artifacts Documentation](https://platform9.github.io/vjailbreak/guides/troubleshooting/vmware_residual_artifacts/) - Scan-based record of leftover VMware artifacts after uninstallation in v0.4.1
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: Group Policy Object (GPO) VM Migration
|
||||
description: Guide for disabling Group Policy settings that may interfere with VM migration operations
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Some Group Policy Object (GPO) settings can interfere with driver injection, which is critical for a successful VM migration. **GPO is a Windows-specific feature** that manages system settings for Windows VMs. Temporarily disabling these policies ensures that driver injection can proceed reliably.
|
||||
|
||||
### What is Affected by GPO
|
||||
|
||||
**Driver installation cannot be done properly, leading to:**
|
||||
- Blue Screen of Death (BSOD)
|
||||
- Windows VM getting stuck in boot loop
|
||||
- Migration failures due to hardware driver conflicts
|
||||
|
||||
### What to Do
|
||||
|
||||
**Option 1: Disable via GUI - Step by Step**
|
||||
|
||||
1. Open Group Policy Editor (`gpedit.msc`)
|
||||
|
||||
2. Navigate to Driver Policies
|
||||
|
||||
Go to:
|
||||
```
|
||||
Computer Configuration
|
||||
→ Administrative Templates
|
||||
→ System
|
||||
→ Device Installation
|
||||
```
|
||||
|
||||
3. Disable ALL restrictive policies here
|
||||
|
||||
Check and set these to Not Configured (or Disabled where applicable):
|
||||
|
||||
- 🚫 **Critical ones (must fix)**
|
||||
- `Prevent installation of devices not described by other policy settings` → Set to Not Configured
|
||||
- `Prevent installation of devices that match any of these device IDs` → Not Configured
|
||||
- `Prevent installation of devices using drivers that match these device setup classes` → Not Configured
|
||||
|
||||
**Option 2: Sure Shot Way - Remove GPO via PowerShell**
|
||||
```powershell
|
||||
Remove-Item -Recurse -Force "C:\Windows\System32\GroupPolicy" -ErrorAction SilentlyContinue
|
||||
Remove-Item -Recurse -Force "C:\Windows\System32\GroupPolicyUsers" -ErrorAction SilentlyContinue
|
||||
Remove-Item -Recurse -Force "HKLM:\Software\Policies" -ErrorAction SilentlyContinue
|
||||
Remove-Item -Recurse -Force "HKCU:\Software\Policies" -ErrorAction SilentlyContinue
|
||||
|
||||
gpupdate /force
|
||||
```
|
||||
|
||||
:::warning
|
||||
The PowerShell method completely removes all local Group Policy settings. Use this only when GUI methods fail or when you need to ensure complete GPO removal.
|
||||
:::
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
title: "Inject Environment Variables"
|
||||
description: "Enabling environment variable injection for the VJB pods using a Kubernetes ConfigMap"
|
||||
---
|
||||
|
||||
Injecting environment variables into the VJB pods is a feature that allows users to inject environment variables into the VJB pods using a Kubernetes ConfigMap.
|
||||
## Injecting Environment Variables During vJailbreak VM Provisioning
|
||||
1. **Cloud-init populates environment variables**
|
||||
|
||||
Users must provide environment variables in the `/etc/pf9/env` file during provisioning, typically using a cloud-init script.
|
||||
|
||||
Example cloud-init configuration using `write_files`:
|
||||
```yaml
|
||||
write_files:
|
||||
- path: /etc/pf9/env
|
||||
content: |
|
||||
http_proxy=http://<proxy-server>:<proxy-port>
|
||||
https_proxy=http://<proxy-server>:<proxy-port>
|
||||
no_proxy=localhost,127.0.0.1
|
||||
permissions: '0644'
|
||||
```
|
||||
|
||||
2. **ConfigMap creation from /etc/pf9/env**
|
||||
|
||||
A helper script or manual command reads `/etc/pf9/env` and creates a Kubernetes ConfigMap named `pf9-env`.
|
||||
This is done while the vjailbreak VM is being provisioned.
|
||||
```bash
|
||||
kubectl create configmap pf9-env --from-env-file=/etc/pf9/env -n migration-system
|
||||
```
|
||||
|
||||
You can either populate the `/etc/pf9/env` file via cloud-init or manually.
|
||||
|
||||
If done manually please follow the steps mentioned in [Injecting Environment Variables Post-Provisioning](#injecting-environment-variables-post-provisioning):
|
||||
|
||||
|
||||
Now this will be picked up by the v2v-helper pod and the proxy variables will be available in the pod and it would be respected by the v2v-helper pod.
|
||||
|
||||
## Injecting Environment Variables Post-Provisioning
|
||||
|
||||
If you would like to inject environment variables after the vjailbreak VM has been provisioned, follow these steps:
|
||||
1. **Delete the existing ConfigMap**
|
||||
|
||||
```bash
|
||||
kubectl delete configmap pf9-env -n migration-system
|
||||
```
|
||||
2. **Populate the `/etc/pf9/env` file with whatever env variables needed**
|
||||
|
||||
```bash
|
||||
echo "http_proxy=http://<proxy-server>:<proxy-port>" >> /etc/pf9/env
|
||||
echo "https_proxy=http://<proxy-server>:<proxy-port>" >> /etc/pf9/env
|
||||
echo "no_proxy=localhost,127.0.0.1" >> /etc/pf9/env
|
||||
```
|
||||
|
||||
3. **Create a new ConfigMap**
|
||||
|
||||
```bash
|
||||
kubectl create configmap pf9-env --from-env-file=/etc/pf9/env -n migration-system
|
||||
```
|
||||
|
||||
4. **Restart the controller manager deployment**
|
||||
|
||||
```bash
|
||||
kubectl rollout restart deployment migration-controller-manager -n migration-system
|
||||
```
|
||||
|
||||
5. **Trigger a new migration for the envs to be reflected in the pod**
|
||||
|
||||
Trigger via UI or via api.
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,145 @@
|
||||
---
|
||||
title: Migration Templates
|
||||
description: Save a migration configuration as a reusable template, then apply it to new migrations instead of filling in the form every time
|
||||
---
|
||||
|
||||
Operators who migrate many VMs usually reuse the same configuration: the same source vCenter, the same destination cluster, the same network and storage mappings, the same copy method and cutover policy. A **Migration Template** saves that configuration once so every later migration can start from it.
|
||||
|
||||
A template stores everything the migration form asks for **except which VMs to migrate**. You pick the VMs fresh each time.
|
||||
|
||||
Templates only pre-fill the form. They do not change how a migration runs — a migration started from a template behaves exactly like one configured by hand.
|
||||
|
||||
## Where templates live
|
||||
|
||||
Open **Migrations** in the vJailbreak UI. It has two tabs, each with a count badge:
|
||||
|
||||
- **Migrations** — the existing migration list.
|
||||
- **Templates** — saved templates.
|
||||
|
||||
The Templates tab toolbar sits inline with the tabs and offers:
|
||||
|
||||
| Control | Behavior |
|
||||
|---|---|
|
||||
| **Search** | Matches the template name and description |
|
||||
| **Filter** (funnel icon) | Filters by migration type — Hot copy, Cold copy, or Mock copy. Choose **Clear filter** to remove it. |
|
||||
| **Sort** | **Newest** (default) or **Name** |
|
||||
| **Grid / list toggle** | Card grid (default) or a dense table |
|
||||
|
||||
## Prerequisites
|
||||
|
||||
At least one VMware credential and one PCD credential must exist. Until both are present, **Create New Template** and **Save as template** are disabled.
|
||||
|
||||
## What a template saves
|
||||
|
||||
| Group | Saved values |
|
||||
|---|---|
|
||||
| Source | VMware credential, source vCenter cluster |
|
||||
| Destination | PCD credential, target PCD cluster |
|
||||
| Mappings | Network mappings, storage mappings, datastore-to-array-credential mappings |
|
||||
| Copy | Storage copy method (standard, vJailbreak Accelerated Copy with its proxy VM, or Storage Accelerated Copy), migration type (hot, cold, or mock), data copy start time |
|
||||
| Cutover | Cutover option — immediate, time window, or admin-initiated — with its start and end times |
|
||||
| Placement | Security groups, server group, DHCP fallback, disconnect source network |
|
||||
| Post-migration | First boot script, post-migration actions (rename VM, move to folder) |
|
||||
| Metadata | Preserve source tags, custom metadata key-value pairs |
|
||||
| Advanced | Network persistence, remove VMware Tools, periodic sync and its interval, image profiles, network conflict acknowledgement, GPU flavor, data-only mode, guest OS family |
|
||||
|
||||
**Not saved**, by design:
|
||||
|
||||
- The VM selection, and anything attached to a specific VM — assigned IPs, MAC preservation, and per-VM flavor.
|
||||
|
||||
## Create a template
|
||||
|
||||
There are three ways to create one.
|
||||
|
||||
### From a migration you are configuring
|
||||
|
||||
1. Click **Start Migration** and fill in the form.
|
||||
2. Click **Save as template** at the bottom left of the form.
|
||||
3. Enter a name, optionally a description, and click **Save template**.
|
||||
|
||||
The form stays open — saving a template does not start or cancel the migration you were configuring.
|
||||
|
||||
### From the Templates tab
|
||||
|
||||
Use this when your goal is the template itself, not a migration.
|
||||
|
||||
1. Open the **Templates** tab and click **Create New Template**.
|
||||
2. The migration form opens in **Create Template** mode. It differs from the normal form in three ways:
|
||||
- There is no **Select VMs** step.
|
||||
- The mapping step lists every network and datastore in the selected source cluster, instead of only those used by selected VMs.
|
||||
- Partial mappings are allowed — you do not have to map everything for the template to be valid.
|
||||
3. Click **Create Template**, name it, and save.
|
||||
|
||||
No migration or migration plan is created by this flow.
|
||||
|
||||
### By cloning
|
||||
|
||||
Click the clone icon on a template card or list row. The copy is named `<original name> (copy)`, or `<original name> (copy) 2` if that name is taken. The original is untouched.
|
||||
|
||||
### Naming rules
|
||||
|
||||
Template names must be unique.
|
||||
|
||||
## Use a template
|
||||
|
||||
Click **Use** on a template card, list row, or in its detail drawer. The **Start Migration** form opens with the template's configuration applied, and every field remains editable.
|
||||
|
||||
You still choose the VMs. Because mappings are saved for the whole cluster while a migration maps only what the selected VMs use, vJailbreak keeps the template's mappings aside and applies them as they become relevant:
|
||||
|
||||
- Before you select any VM, saved mappings are not shown — none of their sources are in play yet.
|
||||
- As you select VMs, each saved mapping whose source network or datastore appears, and whose target still exists on the destination, is applied automatically.
|
||||
- De-selecting a VM removes the mappings only that VM needed. Re-selecting it brings them back.
|
||||
- A mapping you delete by hand stays deleted, and is not re-applied when the VM list changes.
|
||||
|
||||
Submitting the form creates an ordinary migration. The template is not modified, and no link is kept between the two.
|
||||
|
||||
## View template details
|
||||
|
||||
Click a card or row (anywhere except an action button) to open the detail drawer:
|
||||
|
||||
- Name, description, and created date
|
||||
- **Source & Destination** — source credentials, destination credentials, tenant or project, target cluster
|
||||
- **Network & Storage Mappings** — every mapping pair, plus the storage copy method
|
||||
- **Migration Options** — migration mode, cutover, guest OS
|
||||
- **Advanced options** — each option that is set, with its value
|
||||
|
||||
The drawer also carries **Use**, **Edit**, **Clone**, and **Delete** actions.
|
||||
|
||||
## Edit a template
|
||||
|
||||
Templates are editable in place, so infrastructure changes do not force you to delete and recreate them.
|
||||
|
||||
1. Click the pencil icon on the card or list row, or **Edit** in the detail drawer.
|
||||
2. The form opens in **Edit Template** mode, pre-filled the same way **Use** pre-fills it. As in Create Template mode, there is no VM step.
|
||||
3. Change what you need and click **Save Changes**.
|
||||
|
||||
The same template is updated — no duplicate is created, and the name and position in the list stay the same. You can also change the name and description in the save dialog.
|
||||
|
||||
If someone else changed the same template while your form was open, the save fails with an error instead of silently overwriting their change. Reopen the template and reapply your edits.
|
||||
|
||||
## Delete a template
|
||||
|
||||
Click the trash icon on the card or list row, or **Delete** in the detail drawer, then confirm. Deleting a template does not affect migrations already created from it — they hold their own copy of the configuration and continue to run and display normally.
|
||||
|
||||
## Templates from the command line
|
||||
|
||||
Saved templates are `MigrationBlueprint` custom resources in the `migration-system` namespace:
|
||||
|
||||
```bash
|
||||
kubectl -n migration-system get migrationblueprints
|
||||
kubectl -n migration-system get migrationblueprint <name> -o yaml
|
||||
```
|
||||
|
||||
These are separate from the internal, per-session `MigrationTemplate` objects that the migration form creates and cleans up on its own. See [vJailbreak CRDs](../../../reference/reference/#migrationblueprint) for the field list.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
| Symptom | Cause | What to do |
|
||||
|---|---|---|
|
||||
| **Create New Template** and **Save as template** are disabled | No VMware or no PCD credential exists | Add both credentials first |
|
||||
| Cluster dropdowns are empty after clicking **Use** | The saved source or target cluster no longer exists, or its name changed | Select the clusters manually.
|
||||
| Saved mappings do not appear after **Use** | Expected until VMs are selected | Select VMs. Mappings apply as their source networks and datastores come into scope. |
|
||||
| A mapping never reappears after being removed | Mappings deleted by hand are not re-applied | Add the mapping again manually |
|
||||
| Saving reports *"A template named … already exists"* | Names are unique, ignoring case | Pick a different name |
|
||||
| **Save Changes** fails on an edit | The template changed elsewhere since the form opened | Reopen the template and reapply the change |
|
||||
| Templates tab shows "No templates match" | A search term or type filter is active | Clear the search box, or choose **Clear filter** in the filter menu |
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
title: Configuring Dedicated Data Network for Migrations
|
||||
description: How to separate vCenter management traffic from disk-copy data traffic on the vJailbreak VM to avoid network contention and asymmetric routing.
|
||||
---
|
||||
|
||||
In environments where security requirements mandate separate networks for control-plane and storage traffic (e.g., a VMware underlay with a dedicated storage network that differs from the PCD host underlay), a single shared network path for both vCenter API calls and disk-copy data can cause congestion, dropped transfers, or asymmetric routing failures.
|
||||
|
||||
This guide explains the traffic separation design and the routing configuration required on the vJailbreak VM.
|
||||
|
||||
## Architecture Overview
|
||||
|
||||
|
||||
|
||||
The core design: keep vCenter's control-plane traffic and vJailbreak's disk-copy traffic on **physically distinct paths** rather than sharing one network.
|
||||
|
||||
### ESXi Side
|
||||
|
||||
The ESXi host exposes two interfaces:
|
||||
|
||||
| Interface | Role |
|
||||
|-----------|------|
|
||||
| **iface1** | Management — vCenter API calls, general connectivity |
|
||||
| **iface2** | NFC data copy — tagged with `nfc_flag`, bound to VMware's NFC (Network File Copy) service. ESXi streams disk data through this interface during migrations. |
|
||||
|
||||
This split is enforced at the ESXi interface level. Management and data movement never contend for the same physical path.
|
||||
|
||||
### vJailbreak VM Side
|
||||
|
||||
The vJailbreak VM mirrors the same split with two bridges and bonds:
|
||||
|
||||
| Path | Bridge / Bond | Segment | Traffic |
|
||||
|------|--------------|---------|---------|
|
||||
| Management | Bridge-1 / Bond0 | seg1 (default) | vCenter API, management, internet |
|
||||
| Storage | Bridge-2 / Bond1 | seg2 | Disk data copy from ESXi NFC service |
|
||||
|
||||
## Critical: Routing Table Configuration
|
||||
|
||||
This is the most operationally important detail.
|
||||
|
||||
When vJailbreak issues a disk-copy request, ESXi responds using **iface2's IP** — because iface2 is the interface tagged for NFC traffic. If the vJailbreak VM's outbound route for that request is not explicitly pinned to the storage interface (Bridge-2 / Bond1), the following problems occur:
|
||||
|
||||
- **Asymmetric routing** — request exits via the management interface, response arrives via the storage interface; the connection is dropped.
|
||||
- **Silent fallback** — data copy traffic falls back onto the management network, starving it of bandwidth.
|
||||
- **Transfer failures** — the NBD copy fails or times out due to IP mismatch on ESXi's NFC response path.
|
||||
|
||||
### Required Routing Rule
|
||||
|
||||
On the vJailbreak VM, add an explicit route so that any traffic destined for ESXi's NFC/data-copy service (iface2's IP subnet) is routed out through the storage interface:
|
||||
|
||||
```bash
|
||||
# Example: route ESXi storage subnet via the storage interface
|
||||
ip route add <esxi-nfc-subnet>/24 via <gateway> dev <bond1-or-bridge2-interface>
|
||||
```
|
||||
|
||||
Replace:
|
||||
|
||||
- `<esxi-nfc-subnet>` — the subnet of ESXi's iface2 (NFC-tagged interface)
|
||||
- `<gateway>` — the gateway on the storage network segment
|
||||
- `<bond1-or-bridge2-interface>` — the interface name for Bridge-2/Bond1 on the vJailbreak VM
|
||||
|
||||
To make this persistent across reboots, add the route to your network configuration (e.g., `/etc/netplan/*.yaml` or `/etc/network/interfaces` depending on the OS).
|
||||
|
||||
### Verifying the Route
|
||||
|
||||
After adding the route, confirm that traffic to the ESXi NFC IP exits via the correct interface:
|
||||
|
||||
```bash
|
||||
ip route get <esxi-iface2-ip>
|
||||
```
|
||||
|
||||
Expected output should show the storage interface (Bond1/Bridge-2), not the management interface.
|
||||
|
||||
## Summary
|
||||
|
||||
| Concern | Solution |
|
||||
|---------|----------|
|
||||
| Management traffic contending with data copy | Separate physical interfaces on both ESXi and vJailbreak VM |
|
||||
| ESXi NFC responses routed incorrectly | Explicit `ip route` rule on vJailbreak VM pinning NFC subnet to storage interface |
|
||||
| Route lost on reboot | Persist route in OS network configuration |
|
||||
|
||||
Without this routing configuration, bulk disk-copy traffic will bleed onto the management network regardless of the physical interface separation, because ESXi's NFC response will always use iface2's IP and the OS will drop the asymmetric connection.
|
||||
@@ -0,0 +1,356 @@
|
||||
---
|
||||
title: One-Stop Migration Networking
|
||||
description: Find your migration networking situation, apply the right settings, and know exactly what the OpenStack port and the guest OS will look like afterward.
|
||||
---
|
||||
|
||||
Network settings are the most common cause of failed or surprising migrations. This guide is organized by situation: find the scenario that matches yours, apply the settings, and check the expected outcome before you migrate.
|
||||
|
||||
Every scenario reports two separate outcomes:
|
||||
|
||||
- **The OpenStack port** — the address and MAC that OpenStack assigns to the network port.
|
||||
- **Inside the guest** — what the migrated VM's own network configuration looks like on first boot.
|
||||
|
||||
These two can differ. A preserved IP address on the port does not always mean the guest is statically configured to match it.
|
||||
|
||||
:::note
|
||||
For the underlying mechanism behind interface-name persistence and per-OS guest behavior, see [Network Persistence](../../../concepts/network-persistence/).
|
||||
:::
|
||||
|
||||
## Advanced options for migration
|
||||
|
||||
| Setting | What it controls |
|
||||
| --- | --- |
|
||||
| **Preserve IP** | Carry the discovered source IP onto the OpenStack port. |
|
||||
| **IP address box** | Leave as-is (discovered IP), type one IPv4 address, or leave empty. |
|
||||
| **Preserve MAC** | Carry the source MAC, or let OpenStack generate a new one. |
|
||||
| **Fallback to DHCP** | On = accept an OpenStack-assigned address rather than fail. Off = stop the migration on conflict or mismatch. |
|
||||
| **Persist source network interfaces** | Restore the original interface names inside the guest. Only available when Preserve IP is on. |
|
||||
|
||||
## Table of scenarios
|
||||
|
||||
Find the situation that matches yours, read across the row for the settings to apply, then follow the link to the detailed block — expected outcome, port and guest behavior, and the caveats.
|
||||
|
||||
| Scenario | Preserve IP | IP address box | Preserve MAC | Fallback to DHCP | Persist source network interfaces | Details |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| **A** — Same subnet: keep the exact IP and MAC, fail if the address is taken | **On** | Leave as-is | **On** | Off | **On** | [Scenario A →](#a--keep-the-same-ip-and-the-same-mac) |
|
||||
| **B** — Specific new IP | Off | Type one IPv4 address | Either | Off, or on if a DHCP address is acceptable | Unavailable | [Scenario B →](#b--assign-a-specific-new-ip-address) |
|
||||
| **C** — Everything on DHCP | Off on every NIC | Empty | Either | **On** — required | Unavailable | [Scenario C →](#c--force-everything-onto-dhcp) |
|
||||
| **D** — Different subnet | Off | Empty, or an address valid in the new subnet | Either | **On** — required | Unavailable | [Scenario D →](#d--the-destination-is-on-a-different-subnet) |
|
||||
| **E** — Same subnet, bulk move: prefer the IP but accept DHCP rather than fail | **On** | Leave as-is | **On** | **On** | **On** | [Scenario E →](#e--prefer-the-same-ip-but-accept-dhcp-rather-than-fail) |
|
||||
| **F** — L2-only network | No effect on the port | Ignored | Either — on to keep the MAC | Greyed out | Your choice | [Scenario F →](#f--the-destination-is-an-l2-only-network) |
|
||||
| **G** — Same IP, new MAC | **On** | Leave as-is | Off | Your choice | Your choice | [Scenario G →](#g--keep-the-ip-but-let-openstack-pick-a-new-mac) |
|
||||
| **H** — Source VM powered off | Forced off (greyed out) | Type an address, or empty for DHCP | Either — usually on | On if the address box is empty | Unavailable | [Scenario H →](#h--the-source-vm-is-powered-off) |
|
||||
| **I** — Port with no address | Off | Empty | Either | Off | Unavailable | [Scenario I →](#i--create-the-port-with-no-address-at-all) |
|
||||
| **J** — Preserve IP and MAC, Persist Network off | **On** | Leave as-is | **On** | Your choice | Off | [Scenario J →](#j--preserve-ip-and-mac-but-persist-network-is-off) |
|
||||
|
||||
**Reading the table**
|
||||
|
||||
- **Either** / **Your choice** — the setting does not change the outcome the scenario describes.
|
||||
- **Unavailable** — the UI disables **Persist source network interfaces** whenever Preserve IP is off.
|
||||
- **Greyed out** — the UI disables the setting for this scenario; you cannot change it.
|
||||
- **Leave as-is** — do not edit the box; it already shows the discovered IP.
|
||||
|
||||
:::caution
|
||||
Scenarios **C** and **I** share every setting except **Fallback to DHCP**, and Scenarios **A**, **E**, and **J** share every setting except **Fallback to DHCP** and **Persist source network interfaces**. Those single differences change the result substantially, so confirm them against the detailed block before you migrate.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## A — Keep the same IP and the same MAC
|
||||
|
||||
**Use this when**
|
||||
|
||||
- The destination network carries the same subnet as the source.
|
||||
- The VM is powered on and its IP was discovered correctly.
|
||||
- DNS records, firewall rules, or MAC-locked licenses depend on the address surviving the move.
|
||||
|
||||
**Settings**
|
||||
|
||||
| Setting | Value |
|
||||
| --- | --- |
|
||||
| Preserve IP | On |
|
||||
| IP address box | Leave as-is (shows the discovered IP) |
|
||||
| Preserve MAC | On |
|
||||
| Fallback to DHCP | Off — you want the migration to stop rather than silently change the address |
|
||||
| Persist source network interfaces | On — keeps the original interface names too |
|
||||
|
||||
**What you get**
|
||||
|
||||
- **OpenStack port:** the same IP address, provided nothing else in the network already holds it.
|
||||
- **Port MAC:** the same MAC address.
|
||||
- **Inside the guest:** unchanged. A static NIC stays static on the same address; a DHCP NIC stays on DHCP. The original interface names are restored.
|
||||
|
||||
:::caution
|
||||
If the address is already in use, the migration fails with a port conflict. That is deliberate — it stops you from creating a duplicate. Consider ticking **Disconnect source network** so the original VM releases the address first.
|
||||
|
||||
**Persist source network interfaces** must be on for the "unchanged" guarantee above. If it is off, the guest outcome depends on the OS — see [Scenario J](#j--preserve-ip-and-mac-but-persist-network-is-off).
|
||||
:::
|
||||
|
||||
## B — Assign a specific new IP address
|
||||
|
||||
**Use this when**
|
||||
|
||||
- You are re-addressing the VM as part of the move and already know the address it should get.
|
||||
|
||||
**Settings**
|
||||
|
||||
| Setting | Value |
|
||||
| --- | --- |
|
||||
| Preserve IP | Off |
|
||||
| IP address box | Type the new address — one IPv4 address only |
|
||||
| Preserve MAC | Either — your choice |
|
||||
| Fallback to DHCP | Off if a wrong address should stop the migration; on if a DHCP address is an acceptable substitute |
|
||||
| Persist source network interfaces | Unavailable |
|
||||
|
||||
**What you get**
|
||||
|
||||
- **OpenStack port:** the address you typed, provided it belongs to a subnet on the destination network.
|
||||
- If it does not belong to a subnet: the migration fails (Fallback off), or the port gets an OpenStack-assigned address (Fallback on).
|
||||
- **Inside the guest:** DHCP configuration on the assigned address.
|
||||
|
||||
:::caution
|
||||
**One address per NIC.** Two addresses are rejected with "Multiple IPs are not supported when Preserve IP is disabled".
|
||||
|
||||
A typed address carries no prefix length, so the guest assumes `/24`. Verify the netmask if your subnet is not a `/24`.
|
||||
:::
|
||||
|
||||
## C — Force everything onto DHCP
|
||||
|
||||
**Use this when**
|
||||
|
||||
- You want a clean start: OpenStack allocates all addresses and no source addressing is carried over.
|
||||
|
||||
**Settings**
|
||||
|
||||
| Setting | Value |
|
||||
| --- | --- |
|
||||
| Preserve IP | Off on every NIC |
|
||||
| IP address box | Empty |
|
||||
| Preserve MAC | Either — your choice |
|
||||
| Fallback to DHCP | On — required, see below |
|
||||
| Persist source network interfaces | Unavailable |
|
||||
|
||||
**What you get**
|
||||
|
||||
- **OpenStack port:** an address allocated by OpenStack.
|
||||
- **Port MAC:** preserved or newly generated, per your choice.
|
||||
- **Inside the guest:** DHCP.
|
||||
|
||||
:::caution
|
||||
**Fallback to DHCP must be on.** With it off, this same combination produces a port with no address at all — see [Scenario I](#i--create-the-port-with-no-address-at-all).
|
||||
:::
|
||||
|
||||
## D — The destination is on a different subnet
|
||||
|
||||
**Use this when**
|
||||
|
||||
- The destination OpenStack network does not carry the source VM's subnet.
|
||||
|
||||
This is the most common cause of failed migrations.
|
||||
|
||||
**Settings**
|
||||
|
||||
| Setting | Value |
|
||||
| --- | --- |
|
||||
| Preserve IP | Off |
|
||||
| IP address box | Empty (or type an address valid in the new subnet — see [Scenario B](#b--assign-a-specific-new-ip-address)) |
|
||||
| Preserve MAC | Either — your choice |
|
||||
| Fallback to DHCP | On — required |
|
||||
| Persist source network interfaces | Unavailable — the UI greys it out automatically |
|
||||
|
||||
**What you get**
|
||||
|
||||
- **OpenStack port:** an address allocated by OpenStack from the destination subnet.
|
||||
- **Port MAC:** the same MAC if Preserve MAC is on, otherwise a newly generated one.
|
||||
- **Inside the guest:** DHCP.
|
||||
|
||||
:::caution
|
||||
**Preserve IP on** with **Fallback to DHCP off** is the failure case — the port cannot be created and the migration stops, but only if the source NIC actually had an address. A NIC with no discovered IP is fine.
|
||||
|
||||
**Preserve IP on** with **Fallback to DHCP on** is tolerable: you still land on a DHCP address and keep the MAC without editing each NIC. Turning Preserve IP off is clearer.
|
||||
:::
|
||||
|
||||
## E — Prefer the same IP, but accept DHCP rather than fail
|
||||
|
||||
**Use this when**
|
||||
|
||||
- Same subnet as Scenario A, but you are migrating in bulk and would rather a few VMs come up on a different address than have the whole batch stop.
|
||||
|
||||
**Settings**
|
||||
|
||||
| Setting | Value |
|
||||
| --- | --- |
|
||||
| Preserve IP | On |
|
||||
| IP address box | Leave as-is |
|
||||
| Preserve MAC | On |
|
||||
| Fallback to DHCP | On |
|
||||
| Persist source network interfaces | On |
|
||||
|
||||
**What you get**
|
||||
|
||||
- **OpenStack port:** the same IP where possible; an OpenStack-assigned address where not.
|
||||
- **Port MAC:** the same MAC address.
|
||||
- **Inside the guest:** the original static configuration where the address was preserved; DHCP where it was not.
|
||||
|
||||
:::caution
|
||||
You will not be stopped when an address changes. Check the migration report afterward to see which VMs changed address.
|
||||
|
||||
As with Scenario A, the guest outcome above assumes **Persist source network interfaces** is on. If it is off, see [Scenario J](#j--preserve-ip-and-mac-but-persist-network-is-off).
|
||||
:::
|
||||
|
||||
## F — The destination is an L2-only network
|
||||
|
||||
**Use this when**
|
||||
|
||||
- The destination OpenStack network is tagged as an L2 network and has no subnets.
|
||||
|
||||
**Settings**
|
||||
|
||||
| Setting | Value |
|
||||
| --- | --- |
|
||||
| Preserve IP | No effect on the port — no fixed IPs can be assigned |
|
||||
| IP address box | Ignored |
|
||||
| Preserve MAC | Works normally — keep it on if you need the MAC |
|
||||
| Fallback to DHCP | Greyed out |
|
||||
| Persist source network interfaces | Your choice |
|
||||
|
||||
**What you get**
|
||||
|
||||
- **OpenStack port:** created with no fixed IP addresses.
|
||||
- **Port MAC:** preserved or newly generated, per your choice.
|
||||
- **Inside the guest (Ubuntu with netplan):** a wildcard configuration puts every interface on DHCP.
|
||||
|
||||
:::caution
|
||||
Nothing in vJailbreak assigns addresses on an L2 network. Make sure a DHCP server is reachable on that segment, or plan to configure the guest by hand.
|
||||
:::
|
||||
|
||||
## G — Keep the IP but let OpenStack pick a new MAC
|
||||
|
||||
**Use this when**
|
||||
|
||||
- The source MAC clashes with something in the destination, or you are deliberately re-issuing hardware addresses.
|
||||
|
||||
**Settings**
|
||||
|
||||
| Setting | Value |
|
||||
| --- | --- |
|
||||
| Preserve IP | On |
|
||||
| IP address box | Leave as-is |
|
||||
| Preserve MAC | Off |
|
||||
| Fallback to DHCP | Your choice — as in Scenarios A and E |
|
||||
| Persist source network interfaces | Your choice |
|
||||
|
||||
**What you get**
|
||||
|
||||
- **OpenStack port:** the same IP address.
|
||||
- **Port MAC:** a newly generated address. The UI shows a warning triangle next to the NIC to confirm this.
|
||||
- **Inside the guest:** DHCP. The guest cannot match its old static settings to a hardware address it has never seen.
|
||||
|
||||
:::caution
|
||||
Anything license-locked to the MAC address will break.
|
||||
|
||||
Interface names inside the guest may change, because names are recovered by matching on the MAC.
|
||||
:::
|
||||
|
||||
## H — The source VM is powered off
|
||||
|
||||
**Use this when**
|
||||
|
||||
- The VM is not running, so VMware Tools reported no addresses.
|
||||
|
||||
**Settings**
|
||||
|
||||
| Setting | Value |
|
||||
| --- | --- |
|
||||
| Preserve IP | Forced off and greyed out — nothing to preserve |
|
||||
| IP address box | Type the address you want, or leave empty for DHCP |
|
||||
| Preserve MAC | Available, and usually worth keeping on |
|
||||
| Fallback to DHCP | On if you left the address box empty |
|
||||
| Persist source network interfaces | Unavailable |
|
||||
|
||||
**What you get**
|
||||
|
||||
- **OpenStack port:** your typed address, an OpenStack-assigned one, or no address if the box was empty with Fallback off.
|
||||
- **Port MAC:** preserved. The MAC is read from the virtual NIC rather than the guest, so it survives a powered-off migration.
|
||||
- **Inside the guest:** no IP configuration is injected if no address was requested.
|
||||
|
||||
:::tip
|
||||
If you know the VM's address, power it on briefly before migrating so vJailbreak can discover it — that unlocks [Scenario A](#a--keep-the-same-ip-and-the-same-mac).
|
||||
:::
|
||||
|
||||
## I — Create the port with no address at all
|
||||
|
||||
**Use this when**
|
||||
|
||||
- You intend to configure addressing yourself after the migration, and want the port attached but unaddressed.
|
||||
|
||||
Rarely used. If you reached this by accident, you probably wanted [Scenario C](#c--force-everything-onto-dhcp).
|
||||
|
||||
**Settings**
|
||||
|
||||
| Setting | Value |
|
||||
| --- | --- |
|
||||
| Preserve IP | Off |
|
||||
| IP address box | Empty |
|
||||
| Preserve MAC | Either — your choice |
|
||||
| Fallback to DHCP | Off |
|
||||
| Persist source network interfaces | Unavailable |
|
||||
|
||||
**What you get**
|
||||
|
||||
- **OpenStack port:** created and attached, with no fixed IP.
|
||||
- **Port MAC:** preserved or newly generated, per your choice.
|
||||
- **Inside the guest:** that interface is skipped entirely. No address, no DHCP client, nothing.
|
||||
|
||||
:::caution
|
||||
The VM will boot with an unconfigured NIC and no network reachability on it. Have console access ready.
|
||||
:::
|
||||
|
||||
## J — Preserve IP and MAC, but Persist Network is off
|
||||
|
||||
**Use this when**
|
||||
|
||||
- You want the address and MAC carried over, but do not need the original interface names restored.
|
||||
- Or **Persist source network interfaces** was simply left at its default (off) and you want to know what to expect.
|
||||
|
||||
This is the case Scenarios A and E refer to. The port outcome is identical to them — only the guest differs.
|
||||
|
||||
**Settings**
|
||||
|
||||
| Setting | Value |
|
||||
| --- | --- |
|
||||
| Preserve IP | On |
|
||||
| IP address box | Leave as-is |
|
||||
| Preserve MAC | On |
|
||||
| Fallback to DHCP | Your choice — as in Scenarios A and E |
|
||||
| Persist source network interfaces | Off |
|
||||
|
||||
**What you get**
|
||||
|
||||
- **OpenStack port:** exactly as in Scenario A or E — the preserved IP, or a DHCP address if Fallback rescued it.
|
||||
- **Port MAC:** the same MAC address.
|
||||
- **Inside the guest:** this is where it differs, and it depends on the guest OS rather than on the source configuration.
|
||||
|
||||
**Guest outcome by OS**
|
||||
|
||||
| Guest OS | Source NIC was on DHCP | Source NIC was static |
|
||||
| --- | --- | --- |
|
||||
| Ubuntu 17.10 and newer | Converted to a static address — pinned to whatever address it happened to hold when discovered | Stays static on the same address |
|
||||
| Ubuntu older than 17.10 | Stays on DHCP. Only interface-name rules are written | Stays static, per the guest's own configuration |
|
||||
| RHEL family 6 and older | Legacy interface handling runs — verify after boot | Legacy interface handling runs — verify after boot |
|
||||
| RHEL / CentOS / Rocky 7+, SUSE, other Linux | Nothing is written. The guest keeps its own configuration | Nothing is written. The guest keeps its own configuration |
|
||||
| Windows | Nothing is written. The guest keeps its own configuration | Nothing is written. The guest keeps its own configuration |
|
||||
|
||||
On Ubuntu 17.10 and newer, the existing `/etc/netplan` directory is moved aside to `/etc/netplan-bkp` and replaced with a single generated file. Interfaces are renamed `vj0`, `vj1`, and so on, matched by MAC address. The netmask comes from what VMware Tools reported; if it is unknown, `/24` is assumed.
|
||||
|
||||
:::caution
|
||||
On **Ubuntu 17.10 and newer** this rewrites the guest's networking wholesale. A NIC that was on DHCP comes back statically pinned to the address it held at discovery time. If you want it to stay on DHCP, use [Scenario C](#c--force-everything-onto-dhcp).
|
||||
|
||||
On **RHEL 7+, SUSE, other Linux, and Windows**, nothing is written at all. If the conversion renamed the interface, the guest's own configuration will point at a device that no longer exists. Have console access ready.
|
||||
|
||||
On a **multi-homed VM**, only one interface gets a default route, and which one is not predictable. Verify routing after migration.
|
||||
:::
|
||||
|
||||
:::note
|
||||
Whether the source NIC was on DHCP or static is recorded but never acted on directly by vJailbreak. It matters only because it determines what the guest's own untouched configuration says.
|
||||
:::
|
||||
@@ -0,0 +1,134 @@
|
||||
---
|
||||
title: Configure Time Zone and NTP Servers
|
||||
description: Set the vJailbreak appliance time zone and NTP servers from Global Settings, and verify they applied to the host and to system pods
|
||||
---
|
||||
|
||||
The vJailbreak appliance runs in UTC with default public NTP pools unless you change it. Two settings in the UI change that:
|
||||
|
||||
- **Time zone** — the appliance's system time zone. It sets the timestamps in migration logs, controller logs, Grafana dashboards, and the schedule of the version-checker cron job.
|
||||
- **NTP servers** — the time sources the appliance synchronizes against. Needed in air-gapped or restricted networks where the default public pools are unreachable.
|
||||
|
||||
Keeping the appliance's clock accurate matters beyond readable logs: clock drift makes Changed Block Tracking timestamps unreliable during hot migrations.
|
||||
|
||||
Both settings are applied to the appliance host itself, not to migrated VMs.
|
||||
|
||||
## Configure the settings
|
||||
|
||||
1. Open **Global Settings**.
|
||||
2. On the **General** tab, pick a **Timezone**. The dropdown is searchable and lists common IANA zones with their current UTC offset.
|
||||
3. On the **Advanced** tab, enter **NTP Servers** — hostnames or IPv4 addresses, separated by commas or new lines. For example: `ntp1.corp.local, ntp2.corp.local`.
|
||||
4. Click **Save**.
|
||||
|
||||
Saving writes both values to the `vjailbreak-settings` ConfigMap and then applies them to the host. You will see *"Applying time settings..."* followed by *"Time settings applied successfully."*
|
||||
|
||||
### What each combination does
|
||||
|
||||
| Time zone | NTP servers | Result |
|
||||
|---|---|---|
|
||||
| Set | Set | Host uses that zone, synchronizing against your servers |
|
||||
| Set | Empty | Host uses that zone, synchronizing against the default public pools |
|
||||
| Empty | Set | Host stays on UTC, synchronizing against your servers |
|
||||
| Empty | Empty | Host reverts to UTC and time synchronization is turned off |
|
||||
|
||||
Clearing both fields is therefore a full reset to the appliance defaults.
|
||||
|
||||
### Validation
|
||||
|
||||
The form rejects a save when an entry is malformed:
|
||||
|
||||
- A time zone must be one of the listed zones. If the appliance already holds a zone that is not in the list, it appears as `(Legacy) <zone>` so it is not silently discarded.
|
||||
- Each NTP entry must be a hostname or an IPv4 address. URLs, entries containing `/`, and malformed hostnames are rejected with *"Invalid NTP server "…". Use hostnames or IPv4 addresses, separated by commas or new lines."*
|
||||
|
||||
## Both fields lock while migrations run
|
||||
|
||||
If any migration is in a non-terminal phase — anything other than Succeeded, Failed, Validation Failed, or Unknown — the **Timezone** and **NTP Servers** fields are disabled, with the tooltip *"Cannot change timezone while migrations are in progress."*
|
||||
|
||||
Applying time settings restarts the controller, SDK, and UI pods, which would disrupt a running migration. The migration list is polled every 30 seconds, so the fields unlock shortly after the last migration reaches a terminal phase.
|
||||
|
||||
**Reset to Defaults** respects the same rule: while a migration is running it resets every other setting but leaves the time zone and NTP servers at their current values. With no migration running, it resets them along with everything else.
|
||||
|
||||
## Verify the settings
|
||||
|
||||
On the appliance host:
|
||||
|
||||
```bash
|
||||
# Time zone, and whether the clock is synchronized
|
||||
timedatectl
|
||||
timedatectl show --property=NTPSynchronized
|
||||
|
||||
# The NTP servers vJailbreak wrote
|
||||
cat /etc/systemd/timesyncd.conf.d/99-vjailbreak.conf
|
||||
```
|
||||
|
||||
The conf file looks like this:
|
||||
|
||||
```ini
|
||||
[Time]
|
||||
NTP=ntp1.corp.local ntp2.corp.local
|
||||
```
|
||||
|
||||
From Kubernetes:
|
||||
|
||||
```bash
|
||||
# What was saved
|
||||
kubectl -n migration-system get configmap vjailbreak-settings \
|
||||
-o jsonpath='{.data.TIMEZONE}{"\n"}{.data.NTP_SERVERS}{"\n"}'
|
||||
|
||||
# What pods will inherit
|
||||
kubectl -n migration-system get configmap pf9-env -o jsonpath='{.data.TZ}{"\n"}'
|
||||
|
||||
# What a running pod actually has
|
||||
kubectl -n migration-system exec deploy/migration-controller-manager -- printenv TZ
|
||||
```
|
||||
|
||||
A rolling restart takes a couple of minutes to finish, so give the pods time before concluding that `TZ` did not propagate.
|
||||
|
||||
## Configure from the command line
|
||||
|
||||
The two values live in the `vjailbreak-settings` ConfigMap:
|
||||
|
||||
| Key | Format | Empty means |
|
||||
|---|---|---|
|
||||
| `TIMEZONE` | IANA zone, for example `Asia/Calcutta` | Use UTC |
|
||||
| `NTP_SERVERS` | Hostnames or IPv4 addresses, space separated | Use the default public pools |
|
||||
|
||||
```bash
|
||||
kubectl -n migration-system patch configmap vjailbreak-settings --type merge \
|
||||
-p '{"data":{"TIMEZONE":"Asia/Calcutta","NTP_SERVERS":"ntp1.corp.local ntp2.corp.local"}}'
|
||||
```
|
||||
|
||||
:::caution
|
||||
Editing the ConfigMap only records the values. Nothing reaches the host until the apply step runs, which the UI triggers on **Save**. After editing the ConfigMap directly, open Global Settings and save, or call the apply endpoint yourself:
|
||||
|
||||
```bash
|
||||
curl -X POST http://<vjailbreak-vm-ip>/dev-api/sdk/vpw/v1/settings/apply-time-settings \
|
||||
-H 'Content-Type: application/json' -d '{}'
|
||||
```
|
||||
:::
|
||||
|
||||
Values written by hand skip the form's validation. Invalid NTP entries are dropped when the settings are applied, and only the valid ones reach the conf file.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
| Symptom | Cause | What to do |
|
||||
|---|---|---|
|
||||
| Timezone and NTP Servers fields are greyed out | A migration is in a non-terminal phase | Wait for it to finish, or cancel it. The fields unlock within about 30 seconds. |
|
||||
| **Reset to Defaults** left the time zone unchanged | Expected while a migration is running | Reset again once no migration is active |
|
||||
| Save reports *"Failed to apply time settings on the host … Settings were saved; click Save again to retry the apply."* | The values were stored, but the host apply failed | Click **Save** again. If it keeps failing, check the API response. |
|
||||
| UI reports success, but `timedatectl` still shows the old zone | The host notification is best-effort and its failure is not surfaced in the UI | Check the logs for `timesettings:` warnings. A zone that is syntactically valid but not installed on the host fails at this step. |
|
||||
| An NTP server you entered is missing from the conf file | It failed validation and was dropped | Check the logs for `ignoring invalid NTP server entries`. Re-enter it as a plain hostname or IPv4 address. |
|
||||
| Pods still show the old `TZ` | The rolling restart has not finished | Wait, then re-check with `kubectl rollout status` |
|
||||
| The conf file is gone after a save | Expected when the NTP Servers field is empty | Re-enter your servers, or leave it empty to use the default pools |
|
||||
|
||||
Logs for the apply step:
|
||||
|
||||
```bash
|
||||
kubectl -n migration-system logs deploy/migration-vpwned-sdk | grep timesettings
|
||||
```
|
||||
|
||||
## Notes and limitations
|
||||
|
||||
- These settings change the **appliance**, not the VMs being migrated. Migrated guests keep their own time configuration.
|
||||
- Failures after the conf file is written — host notification, service restart, pod restarts, cron job patch — never fail the request and are not shown in the UI. The success message means the settings were saved and applied as far as possible.
|
||||
- A time zone that is not installed on the appliance is stored and reported as applied, but the host time zone does not change. Pick a zone from the dropdown to avoid this.
|
||||
- Invalid NTP entries are silently dropped at apply time. The UI blocks them first, so this affects only values written directly to the ConfigMap.
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: "Perform Admin Cutover"
|
||||
description: "Guide to perform admin cutover over UI and CLI"
|
||||
---
|
||||
|
||||
The **Admin Cutover** feature in vJailbreak is used to finalize a migration after the data transfer is complete.
|
||||
It can be triggered in two ways:
|
||||
1. From the **vJailbreak UI**
|
||||
2. Using **kubectl patch** on the corresponding `Pod` of the migration.
|
||||
|
||||
|
||||
## Admin Cutover from the UI
|
||||
1. Navigate to the migration you want to perform the admin cutover for, in the migration Options column,
|
||||
Select the cutover options and select Admin Initiated Cutover as shown in the Image below.
|
||||
|
||||
|
||||
Once the migration is done with copying data, the status of the migration will change to `waitforAdminCutover`.
|
||||
You can then click on the **Admin Cutover** button to trigger the cutover process.
|
||||
|
||||
|
||||
2. A confirmation dialog will appear. Click on the **Confirm** button to proceed with the admin cutover.
|
||||
|
||||
|
||||
3. After confirming, the migration will start the cutover process.
|
||||
|
||||
|
||||
|
||||
## Admin Cutover using kubectl patch
|
||||
You can also trigger the admin cutover using the `kubectl patch` command.
|
||||
1. First, identify the name of the migration `Pod` you want to perform the admin
|
||||
cutover for. You can do that by doing the following things:
|
||||
* Get the name of the migration namespace. You can find it in the vJailbreak UI under the migration details.
|
||||
```bash
|
||||
kubectl get migration -n migration-system | grep -i <migration-name>
|
||||
migration-name AwaitingAdminCutOve vjb 1h
|
||||
```
|
||||
* Get the podRef of migration object
|
||||
```bash
|
||||
kubectl get migration <migration-name> -n migration-system -o jsonpath='{.spec.podRef}'
|
||||
<pod-name>
|
||||
```
|
||||
|
||||
2. Once you have identified the migration `Pod`, you can trigger the admin cutover by
|
||||
executing the following command:
|
||||
```bash
|
||||
kubectl patch pod <pod-name> -n migration-system -p '{"metadata":{"labels":{"startCutover":"yes"}}}'
|
||||
```
|
||||
Replace `pod-name` with the name of your migration `Pod` and `migration-system` with the name of your migration namespace.
|
||||
@@ -0,0 +1,155 @@
|
||||
---
|
||||
title: Profiles
|
||||
description: Use profiles to apply OpenStack volume image metadata properties to migrated VM boot volumes before migration.
|
||||
---
|
||||
|
||||
Profiles let us define a named set of OpenStack Cinder `volume_image_metadata` properties and apply them to VM boot volumes during migration. This gives us control over how the migrated VM boots and runs in OpenStack — for example, setting the firmware type, disk bus driver, video model, or guest agent settings — without having to configure each migration individually.
|
||||
|
||||
Navigate to the **Profiles** section in the sidebar to view and perform all CRUD operations on profiles.
|
||||
|
||||
## Default Profiles
|
||||
|
||||
vJailbreak ships with two built-in profiles that are created by default as a template:
|
||||
|
||||
### default-linux
|
||||
|
||||
Applies to Linux VMs (`linuxGuest`).
|
||||
|
||||
| Property | Value |
|
||||
|---|---|
|
||||
| `hw_qemu_guest_agent` | `yes` |
|
||||
| `hw_video_model` | `virtio` |
|
||||
| `hw_pointer_model` | `usbtablet` |
|
||||
|
||||
### default-windows
|
||||
|
||||
Applies to Windows VMs (`windowsGuest`).
|
||||
|
||||
| Property | Value |
|
||||
|---|---|
|
||||
| `hw_qemu_guest_agent` | `yes` |
|
||||
| `hw_video_model` | `virtio` |
|
||||
| `hw_pointer_model` | `usbtablet` |
|
||||
| `hw_disk_bus` | `virtio` |
|
||||
| `os_type` | `windows` |
|
||||
|
||||
|
||||
|
||||
:::note
|
||||
Default profiles are marked with a star icon in the Profiles list. We can edit them to change their properties, but their names cannot be changed.
|
||||
:::
|
||||
|
||||
## Creating a Profile
|
||||
|
||||
1. On the Profiles page, click **Add Profile**.
|
||||
2. Fill in the following fields:
|
||||
|
||||
- **Profile Name** — A unique name using lowercase letters, numbers, and hyphens (e.g., `windows-uefi-q35`). The name cannot be changed after creation.
|
||||
- **OS Family** — The type of VM this profile applies to:
|
||||
- `Windows` — Only applied to Windows VMs
|
||||
- `Linux` — Only applied to Linux VMs
|
||||
- `Any (applies to all VMs)` — Applied to every VM regardless of OS
|
||||
- **Description** — Optional. A short note shown in the profile list.
|
||||
- **Image Properties** — One or more key-value pairs of OpenStack volume image metadata. Type directly into the key field or select from the list of known property keys.
|
||||
|
||||
3. Click **Create Profile**.
|
||||
|
||||
### Known Image Property Keys
|
||||
|
||||
The property key field in the profile form offers autocomplete suggestions for common OpenStack volume image metadata keys. The hints shown alongside each key are example values.
|
||||
|
||||
| Key | Example Values |
|
||||
|---|---|
|
||||
| `hw_firmware_type` | `uefi`, `bios` |
|
||||
| `hw_machine_type` | `q35`, `pc-i440fx` |
|
||||
| `hw_disk_bus` | `virtio`, `scsi`, `ide` |
|
||||
| `hw_scsi_model` | `virtio-scsi`, `buslogic` |
|
||||
| `hw_tpm_model` | `tpm-crb`, `tpm-tis` |
|
||||
| `hw_tpm_version` | `1.2`, `2.0` |
|
||||
| `os_secure_boot` | `required`, `disabled`, `optional` |
|
||||
| `os_require_quiesce` | `yes`, `no` |
|
||||
| `os_type` | `windows`, `linux` |
|
||||
| `hw_qemu_guest_agent` | `yes`, `no` |
|
||||
| `hw_video_model` | `virtio`, `qxl`, `vga` |
|
||||
| `hw_cdrom_bus` | `sata`, `ide`, `virtio` |
|
||||
| `hw_boot_menu` | `true`, `false` |
|
||||
| `hw_pointer_model` | `usbtablet`, `ps2mouse` |
|
||||
|
||||
|
||||
|
||||
:::note
|
||||
We are not limited to these keys. Any valid OpenStack Cinder `volume_image_metadata` key can be used.
|
||||
:::
|
||||
|
||||
## Selecting Profiles During Migration
|
||||
|
||||
In the migration form, **Step 4 (Security Groups, Server Group & Profiles)** includes a **Profiles** dropdown. We can select one or more profiles to apply during the migration.
|
||||
|
||||
The dropdown shows only profiles that match the OS family of the VMs we have selected:
|
||||
- If our migration includes Windows VMs, profiles with OS family `Windows` or `Any` are shown.
|
||||
- If our migration includes Linux VMs, profiles with OS family `Linux` or `Any` are shown.
|
||||
|
||||
Step 4 is optional. If we do not select any profiles, no additional image metadata is applied to the boot volumes.
|
||||
|
||||
|
||||
|
||||
## How Multiple Profiles Are Merged
|
||||
|
||||
When we select more than one profile, their properties are combined into a single set before being applied. The merge follows these rules:
|
||||
|
||||
- All unique keys from all selected profiles are included.
|
||||
- If two profiles set the **same key to the same value**, there is no conflict and the value is applied once.
|
||||
- If two profiles set the **same key to different values**, the UI will show a conflict error and prevent adding the second profile until the conflict is resolved.
|
||||
|
||||
This ensures that the final set of properties applied to the boot volume is predictable and unambiguous.
|
||||
|
||||
:::note
|
||||
Properties are applied **in addition to** any metadata that vJailbreak sets automatically (for example, `hw_firmware_type: uefi` for UEFI VMs). If a profile specifies a key that conflicts with automatically set metadata, the profile value will override it.
|
||||
:::
|
||||
|
||||
## Using Profiles via CLI
|
||||
|
||||
A `VolumeImageProfile` is a standard Kubernetes custom resource in the `migration-system` namespace. We can create and manage profiles using `kubectl`.
|
||||
|
||||
**View all profiles:**
|
||||
|
||||
```bash
|
||||
kubectl get volumeimageprofiles -n migration-system
|
||||
```
|
||||
|
||||
**View a profile's details:**
|
||||
|
||||
```bash
|
||||
kubectl get volumeimageprofile default-windows -n migration-system -o yaml
|
||||
```
|
||||
|
||||
**Create a custom profile:**
|
||||
|
||||
```yaml
|
||||
apiVersion: vjailbreak.k8s.pf9.io/v1alpha1
|
||||
kind: VolumeImageProfile
|
||||
metadata:
|
||||
name: windows-uefi-q35
|
||||
namespace: migration-system
|
||||
spec:
|
||||
osFamily: windowsGuest
|
||||
description: Windows VMs with UEFI firmware and Q35 machine type
|
||||
properties:
|
||||
hw_firmware_type: uefi
|
||||
hw_machine_type: q35
|
||||
os_secure_boot: disabled
|
||||
```
|
||||
|
||||
```bash
|
||||
kubectl apply -f windows-uefi-q35.yaml
|
||||
```
|
||||
|
||||
To reference a profile in a `MigrationPlan`, add its name to `spec.advancedOptions.imageProfiles`:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
advancedOptions:
|
||||
imageProfiles:
|
||||
- default-windows
|
||||
- windows-uefi-q35
|
||||
```
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
title: Retry a Failed Migration
|
||||
description: Retry a failed migration from the vJailbreak UI, edit its configuration before retrying, or retry several failed migrations at once
|
||||
---
|
||||
|
||||
When a migration ends in the **Failed** phase, you can retry it directly from the vJailbreak UI instead of building the migration again from scratch. A retry reopens the original configuration in the migration form, so you can correct whatever caused the failure — flavor, network or storage mapping, target cluster, cutover settings, or IP assignments — and start again.
|
||||
|
||||
## What Retry does
|
||||
|
||||
vJailbreak offers two retry actions:
|
||||
|
||||
| Action | Where to find it | What it does |
|
||||
|---|---|---|
|
||||
| **Retry** | Row action in the **Migrations** table, or the **Retry** button on a migration's detail page | Opens the migration form pre-filled with the failed migration's configuration. You can change settings before submitting. |
|
||||
| **Retry Selected** | Toolbar of the **Migrations** table, after selecting rows | Retries every selected failed migration with its existing configuration. No editing. |
|
||||
|
||||
Use **Retry** when the migration failed because of a configuration problem. Use **Retry Selected** when several migrations failed for the same temporary reason — for example, an ESXi host or a target service was briefly unreachable — and nothing needs to change.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- The migration is in the **Failed** phase. The Retry button appears in no other phase.
|
||||
- The migration is retryable. Migrations for VMs with **RDM (Raw Device Mapping) disks** cannot be retried from the UI, because the shared RDM state prevents an automatic retry. For these VMs the Retry button is visible but disabled.
|
||||
- The resources the original migration used still exist: its migration plan, migration template, VMware and OpenStack credentials, and the source VM in the inventory. If any of them is missing, the retry form opens with a banner naming the missing item, and Retry stays disabled.
|
||||
|
||||
## Retry a single migration
|
||||
|
||||
1. Go to **Migrations** and locate the failed migration.
|
||||
2. Click the **Retry** action in the row, or open the migration's detail page and click **Retry**.
|
||||
3. The migration form opens in retry mode, titled **Retry Migration**, and loads the original configuration.
|
||||
4. Review the settings and change what you need. See [What you can edit](#what-you-can-edit).
|
||||
5. Click **Retry**.
|
||||
|
||||
vJailbreak returns you to the migrations list and starts a new migration for that VM using the configuration you submitted.
|
||||
|
||||
:::note
|
||||
Clicking **Cancel** closes the form without changing anything. A cancelled retry never modifies the original migration, plan, or template.
|
||||
:::
|
||||
|
||||
|
||||
### What you can edit
|
||||
|
||||
**Locked during a retry**
|
||||
|
||||
- The VM being retried. A retry always applies to exactly one VM, and the VM list shows only that VM.
|
||||
- Source and destination credentials, and the source cluster.
|
||||
|
||||
**Editable**
|
||||
|
||||
- **Target PCD cluster.** Changing it **clears the network and storage mappings**, because mappings are specific to a cluster. Select new mappings before submitting.
|
||||
- Everything else — mappings, flavor, storage copy method, migration options, advanced options, and IP or MAC overrides.
|
||||
|
||||
## Retry several migrations at once
|
||||
|
||||
1. Go to **Migrations** and select the failed rows using the checkboxes.
|
||||
2. The **Retry Selected (N)** button appears in the toolbar. It appears **only when every selected migration** is failed and retryable. If the selection includes a migration that is not failed, or a VM with RDM disks, the button is hidden.
|
||||
3. Click **Retry Selected**. A confirmation dialog appears, stating that the migrations will be retried without changing their configurations and that source VMs will not be modified.
|
||||
4. Click **Retry** to confirm.
|
||||
|
||||
Each selected migration restarts with its existing configuration. Plans, templates, and mappings are left untouched.
|
||||
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
| Symptom | Cause | What to do |
|
||||
|---|---|---|
|
||||
| Retry is disabled and the tooltip mentions RDM disks | The VM has RDM disks and cannot be retried from the UI | Restart the migration manually. See [Migrating an RDM disk Windows cluster machine using the CLI](../../cli-api/migrating_rdm_disk_windows_cluster_machine_using_cli/). |
|
||||
| Banner: *"Migration plan … no longer exists"* | The plan was deleted after the migration failed | Create a new migration for that VM |
|
||||
| Banner naming a VMware or OpenStack credential | The credential was deleted | Recreate the credential, then retry |
|
||||
| Banner: *"Source VM … is no longer present in the inventory"* | The VM is missing from the VMware inventory, usually after a re-sync or after the VM was removed | Refresh the inventory or add the VM back, then retry |
|
||||
| **Retry failed** banner after submitting | A step of the retry did not complete | The banner shows the underlying error. If the original plan could not be updated, nothing new was created and the original plan is intact — correct the problem and retry again. |
|
||||
| Network and storage mappings are empty | Expected after changing the target cluster | Select mappings for the new cluster |
|
||||
|
||||
## Limitations
|
||||
|
||||
- A retry always creates a plan containing a single VM. You cannot retry several VMs into one shared plan with edits.
|
||||
- **Retry Selected** cannot change configuration. If a migration fails again after a bulk retry, retry it individually and correct its settings.
|
||||
@@ -0,0 +1,94 @@
|
||||
---
|
||||
title: Scale vJailbreak
|
||||
description: You can scale up vJailbreak to perform more parallel migrations
|
||||
---
|
||||
|
||||
vJailbreak can be scaled to perform multiple migrations in parallel by deploying additional `agents`, enabling greater efficiency and workload distribution.
|
||||
|
||||
Additional agents can be created in the Agents tab of the vJailbreak dashboard using the "Scale Up" button. You will need to choose the destination OpenStack credentials, the size of the agent VM(s), and the number of agent nodes up to a maximum of 5 per scale up. Additional agent nodes can be scaled up in batches of 5, providing the flexibility to change agent VM sizes to help with throttling network traffic.
|
||||
|
||||
:::caution
|
||||
It is entirely possible to fully saturate a 10Gb network with many parallel migrations!
|
||||
:::
|
||||
|
||||
## Agent Node Sizing and Migration Capacity
|
||||
|
||||
:::caution
|
||||
The sizing recommendations below apply to **agent nodes only**. The primary vJailbreak VM hosts additional services (controller, UI, Prometheus, Grafana, etc.) in addition to running migrations, and therefore requires separate capacity planning with additional overhead. Agent nodes are dedicated worker nodes that primarily run migration pods.
|
||||
:::
|
||||
|
||||
Each migration running on an agent node consumes the following resources:
|
||||
|
||||
| Resource | Request | Limit |
|
||||
|----------|---------|-------|
|
||||
| CPU | 1 core | 2 cores |
|
||||
| Memory | 1 GiB | 3 GiB |
|
||||
| Ephemeral Storage | 3 GiB | 3 GiB |
|
||||
|
||||
### Calculating Concurrent Migrations per Agent
|
||||
|
||||
The number of concurrent migrations an agent node can handle depends on its available resources. While Kubernetes uses **resource requests** for scheduling decisions, the actual resource consumption during migration is closer to the **limits**. Therefore, consider both when planning capacity:
|
||||
|
||||
**Scheduling Capacity (based on requests):**
|
||||
- Maximum Concurrent Migrations = min(Available CPU / 1 core, Available Memory / 1 GiB, Available Storage / 3 GiB)
|
||||
|
||||
**Actual Runtime Capacity (based on limits):**
|
||||
- Maximum Concurrent Migrations = min(Available CPU / 2 cores, Available Memory / 3 GiB, Available Storage / 3 GiB)
|
||||
|
||||
For safe capacity planning, use the **limits-based calculation** to ensure migrations have sufficient resources during peak usage.
|
||||
|
||||
### Recommended Agent Flavors
|
||||
|
||||
Below are recommended OpenStack flavors for agent nodes based on desired migration capacity. Reserve approximately **20-25% of resources** for system overhead (OS, K3s, monitoring, etc.):
|
||||
|
||||
| Agent Flavor | vCPUs | RAM | Storage | Concurrent Migrations (per agent) | Use Case |
|
||||
|--------------|-------|-----|---------|-----------------------------------|----------|
|
||||
| **Small** | 8 | 16 GiB | 60 GiB | 2-3 | Small-scale migrations, testing |
|
||||
| **Medium** | 16 | 32 GiB | 100 GiB | 5-7 | Standard production workloads |
|
||||
| **Large** | 32 | 64 GiB | 200 GiB | 10-14 | High-throughput migrations |
|
||||
| **X-Large** | 48 | 96 GiB | 300 GiB | 15-21 | Maximum parallel migrations |
|
||||
|
||||
:::note
|
||||
Agent nodes require a **minimum of 60 GiB disk storage**. Flavors with less than 60 GiB are not supported.
|
||||
:::
|
||||
|
||||
**Example Calculation for Medium Flavor (16 vCPU, 32 GiB RAM):**
|
||||
- Available CPU after overhead: ~12 cores → 12 / 2 = 6 migrations
|
||||
- Available Memory after overhead: ~24 GiB → 24 / 3 = 8 migrations
|
||||
- **Effective capacity: 6 concurrent migrations** (limited by CPU)
|
||||
|
||||
### Best Practices
|
||||
|
||||
- **Network bandwidth** is often the bottleneck. Monitor network utilization and adjust agent count/size accordingly.
|
||||
- **Storage I/O** on the agent node should be sufficient for temporary disk operations during migration.
|
||||
- Start with **Medium** flavors and scale up based on observed resource utilization and network capacity.
|
||||
- Distribute migrations across multiple smaller agents rather than one large agent for better fault tolerance.
|
||||
- Monitor agent resource usage via the vJailbreak dashboard or Prometheus metrics to optimize sizing.
|
||||
|
||||
Agent nodes can be scaled down by selecting the agent and using the "Scale Down" button.
|
||||
|
||||
## Scaling in L2-Only Networks (PCD)
|
||||
|
||||
Agent scale-up **is supported** in L2-only network environments in PCD.
|
||||
|
||||
### How it works
|
||||
|
||||
1. **vJailbreak recognises the L2-only network** and creates the agent VM on it without asking PCD to assign an IP address.
|
||||
2. **The agent VM waits for its IP address.** On first boot it waits for the external DHCP server on that network to give it an IP address and a default route. It keeps retrying every minute for as long as it takes, so a slow lease is not a problem.
|
||||
3. **The agent joins vJailbreak.** As soon as the guest has an IP address, the agent setup runs and the agent joins the primary vJailbreak VM. Everything it needs is already built into the image, so it does not require internet access.
|
||||
4. **The agent becomes available.** While the agent is still coming up, the Agents tab shows no IP address for it. Once it reports `Ready`, its IP address appears and it starts picking up migrations.
|
||||
|
||||
:::note
|
||||
If an agent stays in `VMCreated` and never becomes `Ready`, the guest most likely never received a DHCP lease or a default route. Open the agent VM console and check `/var/log/pf9-install.log` — the wait loop logs which of the two conditions is still missing.
|
||||
:::
|
||||
|
||||
## Logging into Agent VMs
|
||||
|
||||
Agent VMs use the same login process as the primary vJailbreak VM:
|
||||
- **Username**: `ubuntu`
|
||||
- **Default Password**: `password`
|
||||
- On first login, you will be prompted to change the password immediately.
|
||||
|
||||
:::note
|
||||
VDDK libraries are automatically synced from the primary vJailbreak VM to all agent nodes. You only need to upload VDDK to the primary vJailbreak VM.
|
||||
:::
|
||||
@@ -0,0 +1,356 @@
|
||||
---
|
||||
title: Stream Logs
|
||||
description: How to setup rsyslog to stream logs from vJailbreak VMs to fluentd and integrate with Loki
|
||||
---
|
||||
In this guide, we will cover how to enable the streaming of syslogs from vJailbreak VMs to fluentd and integrate with Loki running on the PCD-CE.
|
||||
For this tutorial you will need working knowledge of K3s, fluentd and Loki.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- A running vJailbreak instance with SSH enabled.
|
||||
- A running fluentd instance on a remote host (in this case PCD-CE Management host).
|
||||
- A running grafana/loki-stack instance for this we are using PCD-CE.
|
||||
|
||||
### Setup vJailbreak VM for rsyslog
|
||||
|
||||
1. Enable K3s to write to `syslog`
|
||||
2. Install rsyslog on the vJailbreak VM - If not already present
|
||||
3. Configure rsyslog to forward syslogs to fluentd.
|
||||
4. Configure loki to read logs from fluentd log directory.
|
||||
|
||||
### Enable syslog for k3s
|
||||
|
||||
To the service section add the following:
|
||||
|
||||
```shell
|
||||
sudo vi /etc/systemd/system/k3s.service
|
||||
```
|
||||
|
||||
```shell
|
||||
[Service]
|
||||
Type=notify
|
||||
NotifyAccess=all
|
||||
```
|
||||
|
||||
To the `ExecStart` section add the following:
|
||||
|
||||
```shell
|
||||
ExecStart=/usr/local/bin/k3s \
|
||||
server --log=/var/log/syslog \
|
||||
'--disable' \
|
||||
'traefik' \
|
||||
```
|
||||
|
||||
```shell
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart k3s
|
||||
```
|
||||
|
||||
### Configure rsyslog
|
||||
|
||||
1. Edit the rsyslog configuration file
|
||||
2. Add the following configuration:
|
||||
|
||||
```shell
|
||||
sudo sh -c 'echo "*.* @<fluentd-host>:5140" >> /etc/rsyslog.d/90-fluentd.conf'
|
||||
```
|
||||
!note: Change `<fluentd-host>` to the IP address of the fluentd host
|
||||
|
||||
3. Restart rsyslog
|
||||
|
||||
```shell
|
||||
sudo systemctl restart rsyslog
|
||||
```
|
||||
|
||||
4. Test rsyslog
|
||||
|
||||
```shell
|
||||
sudo journalctl -f
|
||||
```
|
||||
|
||||
### Install fluentd
|
||||
|
||||
1. Install fluentd on the PCD-CE Management host
|
||||
2. Test fluentd
|
||||
|
||||
```shell
|
||||
$ ulimit -n
|
||||
65536
|
||||
```
|
||||
|
||||
Please add the following lines to your `/etc/security/limits.conf` file:
|
||||
|
||||
```shell
|
||||
root soft nofile 65536
|
||||
root hard nofile 65536
|
||||
* soft nofile 65536
|
||||
* hard nofile 65536
|
||||
```
|
||||
|
||||
3. Setup sysctl conf
|
||||
|
||||
Edit `/etc/sysctl.conf` and add the following
|
||||
|
||||
```shell
|
||||
net.core.somaxconn = 1024
|
||||
net.core.netdev_max_backlog = 5000
|
||||
net.core.rmem_max = 16777216
|
||||
net.core.wmem_max = 16777216
|
||||
net.ipv4.tcp_wmem = 4096 12582912 16777216
|
||||
net.ipv4.tcp_rmem = 4096 12582912 16777216
|
||||
net.ipv4.tcp_max_syn_backlog = 8096
|
||||
net.ipv4.tcp_slow_start_after_idle = 0
|
||||
net.ipv4.tcp_tw_reuse = 1
|
||||
net.ipv4.ip_local_port_range = 10240 65535
|
||||
fs.inotify.max_user_instances = 1024
|
||||
# If forward uses port 24224, reserve that port number for use as an ephemeral port.
|
||||
# If another port, e.g., monitor_agent uses port 24220, add a comma-separated list of port numbers.
|
||||
# net.ipv4.ip_local_reserved_ports = 24220,24224
|
||||
net.ipv4.ip_local_reserved_ports = 24224
|
||||
```
|
||||
|
||||
Then check if these are in effect
|
||||
|
||||
```shell
|
||||
$ sysctl -p
|
||||
net.core.somaxconn = 1024
|
||||
net.core.netdev_max_backlog = 5000
|
||||
net.core.rmem_max = 16777216
|
||||
net.core.wmem_max = 16777216
|
||||
net.ipv4.tcp_wmem = 4096 12582912 16777216
|
||||
net.ipv4.tcp_rmem = 4096 12582912 16777216
|
||||
net.ipv4.tcp_max_syn_backlog = 8096
|
||||
net.ipv4.tcp_slow_start_after_idle = 0
|
||||
net.ipv4.tcp_tw_reuse = 1
|
||||
net.ipv4.ip_local_port_range = 10240 65535
|
||||
fs.inotify.max_user_instances = 1024
|
||||
net.ipv4.ip_local_reserved_ports = 24224
|
||||
```
|
||||
|
||||
4. Install fluentd
|
||||
|
||||
```shell
|
||||
sudo curl -fsSL https://toolbelt.treasuredata.com/sh/install-ubuntu-jammy-fluent-package5.sh | bash
|
||||
```
|
||||
|
||||
5. Restart fluentd
|
||||
|
||||
```shell
|
||||
sudo systemctl restart fluentd
|
||||
```
|
||||
|
||||
6. Test fluentd
|
||||
|
||||
```shell
|
||||
sudo systemctl status fluentd
|
||||
```
|
||||
|
||||
### Configure fluentd
|
||||
|
||||
1. Edit the fluentd configuration file `/etc/fluentd/fluentd.conf`
|
||||
2. Add the following configuration:
|
||||
|
||||
```shell
|
||||
<source>
|
||||
@type syslog
|
||||
port 5140
|
||||
bind 0.0.0.0
|
||||
tag system
|
||||
</source>
|
||||
|
||||
<match system.**>
|
||||
@type stdout
|
||||
</match>
|
||||
```
|
||||
|
||||
Ref: https://docs.fluentd.org/how-to-guides/parse-syslog
|
||||
|
||||
3. Restart fluentd
|
||||
|
||||
```shell
|
||||
sudo systemctl restart fluentd
|
||||
```
|
||||
|
||||
Generally, the logs should now show up in `/var/log/fluent/fluentd.log`.
|
||||
|
||||
### Verify
|
||||
|
||||
1. Check that rsyslog is running
|
||||
|
||||
```shell
|
||||
sudo systemctl status rsyslog
|
||||
```
|
||||
|
||||
2. Check that fluentd is running
|
||||
|
||||
```shell
|
||||
sudo systemctl status fluentd
|
||||
```
|
||||
|
||||
3. Check that syslogs from vJailbreak is being sent to the fluentd
|
||||
|
||||
```shell
|
||||
vjb$ logger -p vjailbreak.notice "This is a test message from Rsyslog - Hello Openstack!"
|
||||
```
|
||||
|
||||
4. Check that fluentd is receiving the logs
|
||||
|
||||
```shell
|
||||
pcd$ tail -f /var/log/fluent/fluentd.log
|
||||
```
|
||||
|
||||
### Setup Loki on PCD-CE
|
||||
|
||||
1. Login to the PCD-CE Management Host
|
||||
2. Then export the kubeconfig
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
|
||||
```
|
||||
|
||||
3. Install Loki using helm
|
||||
Use the following loki-config.yaml
|
||||
|
||||
```
|
||||
loki:
|
||||
image:
|
||||
tag: 2.9.3
|
||||
enabled: true
|
||||
|
||||
grafana:
|
||||
enabled: false
|
||||
|
||||
promtail:
|
||||
enabled: true
|
||||
|
||||
config:
|
||||
server:
|
||||
http_listen_port: 3101
|
||||
grpc_listen_port: 0
|
||||
positions:
|
||||
filename: /tmp/positions.yaml
|
||||
clients:
|
||||
- url: http://loki:3100/loki/api/v1/push
|
||||
snippets:
|
||||
extraScrapeConfigs: |-
|
||||
- job_name: fluentd
|
||||
static_configs:
|
||||
- targets:
|
||||
- localhost
|
||||
labels:
|
||||
job: fluentd
|
||||
__path__: /hostlogs/fluent/*.log
|
||||
pipeline_stages:
|
||||
- match:
|
||||
selector: '{job="fluentd"}'
|
||||
stages:
|
||||
- regex:
|
||||
expression: '.*'
|
||||
- timestamp:
|
||||
source: time
|
||||
format: RFC3339
|
||||
- output:
|
||||
source: message
|
||||
|
||||
extraVolumes:
|
||||
- name: host-logs
|
||||
hostPath:
|
||||
path: /var/log/fluent
|
||||
type: Directory
|
||||
- name: tmp
|
||||
emptyDir: {}
|
||||
|
||||
extraVolumeMounts:
|
||||
- name: host-logs
|
||||
mountPath: /hostlogs/fluent
|
||||
readOnly: true
|
||||
- name: tmp
|
||||
mountPath: /tmp
|
||||
|
||||
serviceAccount:
|
||||
create: true
|
||||
|
||||
rbac:
|
||||
create: true
|
||||
|
||||
persistence:
|
||||
enabled: true
|
||||
size: 10Gi
|
||||
storageClassName: ""
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
```
|
||||
|
||||
```shell
|
||||
helm upgrade --namespace pcd-community --install loki grafana/loki-stack -f loki-config.yaml
|
||||
```
|
||||
|
||||
4. Check if all the loki pods are `running`
|
||||
|
||||
```shell
|
||||
kubectl get pods -n pcd-community | grep loki
|
||||
```
|
||||
|
||||
5. Add Loki as a data source in Grafana
|
||||
|
||||
- Add it manually in the grafana UI
|
||||
Configuration > "Add Datasource" > Loki > "url: http://loki:3100" > "Save & Test"
|
||||
- Add it using a configmap
|
||||
|
||||
Add the configmap
|
||||
|
||||
```shell
|
||||
kubectl apply -f loki-datasource.yaml
|
||||
```
|
||||
|
||||
Restart the deployment
|
||||
|
||||
```shell
|
||||
kubectl rollout restart deployment prometheus-stack-grafana
|
||||
```
|
||||
|
||||
Go to "Explore" > "Loki" to start exploring the logs.
|
||||
|
||||
6. You can use the query below to browse the logs
|
||||
|
||||
```shell
|
||||
{job="fluentd"} |= ``
|
||||
```
|
||||
|
||||
### Flow of Logs
|
||||
```mermaid
|
||||
architecture-beta
|
||||
group vJailbreak(server)[vJailbreak VM]
|
||||
service k3s(logos:kubernetes)[K3s] in vJailbreak
|
||||
service syslog(disk)[Syslog] in vJailbreak
|
||||
service rsyslogd(internet)[rsyslogd] in vJailbreak
|
||||
|
||||
group PCD(server)[PCD]
|
||||
service fluentd(disk)[fluentd] in PCD
|
||||
service loki(database)[Loki] in PCD
|
||||
service grafana(logos:grafana)[Grafana] in PCD
|
||||
|
||||
k3s:L -- R:syslog
|
||||
syslog:B -- T:rsyslogd
|
||||
rsyslogd:R -- R:fluentd
|
||||
fluentd:B -- T:loki
|
||||
loki:L -- R:grafana
|
||||
|
||||
```
|
||||
|
||||
### Version of tools used
|
||||
|
||||
1. Fluentd
|
||||
|
||||
```shell
|
||||
fluentd --version
|
||||
fluent-package 5.2.0 fluentd 1.18.0 (46372ddd521870f6a203baefb5a598209486d0bc)
|
||||
```
|
||||
|
||||
2. Loki & grafana
|
||||
|
||||
```shell
|
||||
NAME CHART APP VERSION
|
||||
grafana grafana-8.11.1 11.6.0
|
||||
loki loki-stack-2.10.2 v2.9.3
|
||||
```
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
title: Upgrade vJailbreak
|
||||
description: How to upgrade vJailbreak to a later version
|
||||
---
|
||||
|
||||
vJailbreak supports an in-place upgrade feature to go from one version to other higher version. This feature is supported starting from v0.4.0 as the base to subsequent versions.
|
||||
|
||||
During the upgrade, only container images, ConfigMaps, and Custom Resource Definitions (CRDs) are modified. We currently do not support the upgrade of the base vJailbreak image or existing Custom Resources (CRs). Therefore, a pre-upgrade cleanup of these resources is required.
|
||||
|
||||
## Upgrade Process
|
||||
|
||||
### 1. Check for Updates
|
||||
Look for the **Upgrade Available** button at the bottom left of the vJailbreak navigation sidebar. Clicking this button will open the Upgrade vJailbreak modal.
|
||||
|
||||
|
||||
|
||||
### 2. Pre-Upgrade Cleanup
|
||||
Before upgrading, vJailbreak requires a cleanup of existing resources to ensure a smooth transition. The pre-upgrade checklist includes:
|
||||
- Delete MigrationPlans
|
||||
- Delete RollingMigrationPlans
|
||||
- Scale down Agents
|
||||
- Delete VMware credentials
|
||||
- Delete PCD credentials
|
||||
- Delete Custom Resources
|
||||
|
||||
Click the **Cleanup** button to initiate this process. Wait for all items to show a green checkmark and the "Cleanup completed successfully" message to appear.
|
||||
|
||||
|
||||
|
||||
|
||||
### 3. Select Version
|
||||
Once the cleanup is successful, click the **Select a version...** dropdown and choose the target version you wish to upgrade to (e.g., `v0.4.1`).
|
||||
|
||||
|
||||
|
||||
### 4. Initiate Upgrade
|
||||
With the version selected, the **Upgrade** button will become enabled. Click it to start the upgrade process.
|
||||
|
||||
|
||||
|
||||
### 5. Wait for Completion
|
||||
You will see an "Upgrading" spinner and a warning: **Processing. Please do not close or refresh this page.** Wait for the process to complete.
|
||||
|
||||
|
||||
|
||||
Once the upgrade is marked as successfully completed, the UI will hold on the screen for 3 seconds before automatically refreshing.
|
||||
|
||||
:::tip[Recommendation]
|
||||
For safety, it is highly advised to perform a **hard refresh** of your browser before using the UI immediately after an upgrade.
|
||||
:::
|
||||
|
||||
:::caution[Important]
|
||||
Do not close or refresh your browser window while the upgrade is in progress, as this may interrupt the operation.
|
||||
:::
|
||||
|
||||
## Check for update before scheduled interval
|
||||
|
||||
If you do not want to wait for the next scheduled check, you can manually trigger the `vjailbreak-version-checker` CronJob to detect if a newer version (e.g., v0.4.1) is available.
|
||||
|
||||
Temporarily modify the schedule to trigger it. Example (run after 5 minutes):
|
||||
```yaml
|
||||
# Change the schedule line in the cronjob to:
|
||||
schedule: "*/5 * * * *"
|
||||
```
|
||||
|
||||
After the CronJob runs, a new pod will be created. Check the pod logs to verify whether an upgrade is available:
|
||||
```bash
|
||||
kubectl get pods -n migration-system
|
||||
kubectl logs <cronjob-pod-name> -n migration-system
|
||||
```
|
||||
|
||||
If v0.4.1 is available, the logs will indicate the upgrade availability.
|
||||
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: Inject VirtIO Windows Driver
|
||||
description: Adds support for user-uploaded virtio-win.iso files used during Windows VM migrations. If the ISO is present at /home/ubuntu/virtio-win/virtio-win.iso, it is used directly and propagated to agents. If missing, vJailbreak attempts to download it. Migration fails gracefully if both methods are unavailable.
|
||||
---
|
||||
|
||||
:::note
|
||||
This feature is available from vJailbreak v0.1.13 and later.
|
||||
:::
|
||||
|
||||
## How to use user-provided virtio-win.iso
|
||||
|
||||
Users can upload the `virtio-win.iso` to the following path on vJailbreak master node:
|
||||
|
||||
```bash
|
||||
/home/ubuntu/virtio-win/virtio-win.iso
|
||||
```
|
||||
|
||||
:::note
|
||||
In vjailbreak VM there is already a folder named `virtio-win` at `/home/ubuntu/`. Please make sure to upload to that directory and the name of the file should be `virtio-win.iso`.
|
||||
:::
|
||||
|
||||
|
||||
## How it works
|
||||
|
||||
If the user has scaled up vJailbreak, the ISO is propagated to all the agents.
|
||||
When a Windows VM migration is initiated:
|
||||
|
||||
The migration logic checks for `/home/ubuntu/virtio-win/virtio-win.iso` on the source node.
|
||||
|
||||
- **If found:**
|
||||
- The ISO is used for injecting **VirtIO drivers** into the migrated disk.
|
||||
- The ISO is **automatically propagated** to all agent nodes if needed.
|
||||
- **If not found:**
|
||||
- vJailbreak attempts to **download** the ISO from a known upstream source (e.g., [fedoraproject.org](https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/)).
|
||||
- **If both methods fail:**
|
||||
- Migration fails gracefully with a clear error message.
|
||||
|
||||
:::note[Does not apply to LDM system volumes]
|
||||
Offline driver injection requires `virt-v2v` to write into the guest filesystem.
|
||||
Windows VMs whose system volume is on a dynamic disk (LDM) skip conversion
|
||||
entirely, so this ISO is not used for them — the VirtIO drivers must be installed
|
||||
on the **source** VM instead. See
|
||||
[Windows Dynamic Disk (LDM) Migration](../windows-ldm-migration/).
|
||||
:::
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,310 @@
|
||||
---
|
||||
title: "Use vJailbreak Settings"
|
||||
description: "How to modify global settings for vJailbreak using the vjailbreak-settings ConfigMap"
|
||||
---
|
||||
|
||||
The vjailbreak-settings ConfigMap provides a centralized way to customize and override default settings in the vJailbreak system. This guide shows you how to use this ConfigMap effectively.
|
||||
|
||||
## Overview
|
||||
|
||||
The vjailbreak-settings ConfigMap allows you to:
|
||||
- Override system-wide default values
|
||||
- Enable or disable optional features
|
||||
- Configure global system behaviors
|
||||
- Set resource limits and operational parameters
|
||||
|
||||
## Checking for the ConfigMap
|
||||
|
||||
In vJailbreak v0.3.0 and above, the `vjailbreak-settings` ConfigMap should already exist in your cluster. If it doesn't exist, you're likely using an older version and should upgrade to v0.3.0 or above.
|
||||
|
||||
To check if the ConfigMap exists:
|
||||
|
||||
```bash
|
||||
kubectl get configmap vjailbreak-settings -n migration-system
|
||||
```
|
||||
|
||||
If you receive an error that the ConfigMap doesn't exist, please upgrade your vJailbreak installation to the latest version.
|
||||
|
||||
## Available Settings
|
||||
|
||||
The vjailbreak-settings ConfigMap supports the following settings:
|
||||
|
||||
| Setting | Description | Default Value | Example Values |
|
||||
|---------|-------------|---------------|---------------|
|
||||
| `AUTO_FSTAB_UPDATE` | Automatically update fstab during migration | `false` | `true`, `false` |
|
||||
| `AUTO_PXE_BOOT_ON_CONVERSION` | Automatically configure PXE boot during conversion | `false` | `true`, `false` |
|
||||
| `CHANGED_BLOCKS_COPY_ITERATION_THRESHOLD` | Number of iterations to copy changed blocks during hot migration | `20` | Any positive integer |
|
||||
| `CLEANUP_PORTS_AFTER_MIGRATION_FAILURE` | Automatically cleanup OpenStack ports after migration failure | `false` | `true`, `false` |
|
||||
| `CLEANUP_VOLUMES_AFTER_CONVERT_FAILURE` | Automatically cleanup OpenStack volumes after conversion failure | `false` | `true`, `false` |
|
||||
| `DEFAULT_MIGRATION_METHOD` | Default method for VM migration | `cold` | `hot` (migrate while VM is running), `cold` (power off VM before migration) |
|
||||
| `DEPLOYMENT_NAME` | Name of the vJailbreak deployment | `vJailbreak` | Any string |
|
||||
| `NTP_SERVERS` | NTP servers the appliance synchronizes against. | Empty (default public pools) | Space-separated hostnames or IPv4 addresses (e.g., `ntp1.corp.local ntp2.corp.local`) |
|
||||
| `OPENSTACK_CREDS_REQUEUE_AFTER_MINUTES` | Interval in minutes to requeue OpenStack credentials validation | `60` | Any positive integer |
|
||||
| `PERIODIC_SYNC_INTERVAL` | Interval for periodic sync during admin cutover | `1h` | Duration format (e.g., `30m`, `1h`, `2h`) |
|
||||
| `PERIODIC_SYNC_MAX_RETRIES` | Maximum number of retries for periodic sync | `3` | Any positive integer |
|
||||
| `PERIODIC_SYNC_RETRY_CAP` | Maximum duration to retry periodic sync | `3h` | Duration format (e.g., `1h`, `3h`, `6h`) |
|
||||
| `POPULATE_VMWARE_MACHINE_FLAVORS` | Automatically populate flavor recommendations for VMware machines | `true` | `true`, `false` |
|
||||
| `TIMEZONE` | System time zone of the vJailbreak appliance. | Empty (UTC) | IANA time zone (e.g., `Asia/Calcutta`, `America/New_York`) |
|
||||
| `VALIDATE_RDM_OWNER_VMS` | Validates that all VMs linked to an RDM disk are migrated in a single migration plan | `true` | `true`, `false` |
|
||||
| `VCENTER_LOGIN_RETRY_LIMIT` | Number of retries for vCenter login attempts | `5` | Any positive integer |
|
||||
| `VCENTER_SCAN_CONCURRENCY_LIMIT` | Maximum number of vCenter VMs to scan concurrently | `10` | Any positive integer |
|
||||
| `VM_ACTIVE_WAIT_INTERVAL_SECONDS` | Interval to wait for VM to become active (in seconds) | `20` | Any positive integer |
|
||||
| `VM_ACTIVE_WAIT_RETRY_LIMIT` | Number of retries to wait for VM to become active | `15` | Any positive integer |
|
||||
| `VMWARE_CREDS_REQUEUE_AFTER_MINUTES` | Interval in minutes to requeue VMware credentials validation | `60` | Any positive integer |
|
||||
| `VOLUME_AVAILABLE_WAIT_INTERVAL_SECONDS` | Interval to wait for volume to become available (in seconds) | `10` | Any positive integer |
|
||||
| `VOLUME_AVAILABLE_WAIT_RETRY_LIMIT` | Number of retries to wait for volume to become available | `15` | Any positive integer |
|
||||
| `HTTP_TIMEOUT_SECONDS` | Timeout in seconds for HTTP requests made by the controller | `30` | Any positive integer |
|
||||
| `V2V_HELPER_POD_CPU_REQUEST` | CPU request for v2v-helper migration pods | `1000m` | Kubernetes CPU quantity (e.g., `500m`, `2000m`) |
|
||||
| `V2V_HELPER_POD_CPU_LIMIT` | CPU limit for v2v-helper migration pods | `2000m` | Kubernetes CPU quantity |
|
||||
| `V2V_HELPER_POD_MEMORY_REQUEST` | Memory request for v2v-helper migration pods | `1Gi` | Kubernetes memory quantity (e.g., `512Mi`, `2Gi`) |
|
||||
| `V2V_HELPER_POD_MEMORY_LIMIT` | Memory limit for v2v-helper migration pods | `3Gi` | Kubernetes memory quantity |
|
||||
| `V2V_HELPER_POD_EPHEMERAL_STORAGE_REQUEST` | Ephemeral storage request for v2v-helper migration pods | `3Gi` | Kubernetes storage quantity (e.g., `5Gi`, `20Gi`) |
|
||||
| `V2V_HELPER_POD_EPHEMERAL_STORAGE_LIMIT` | Ephemeral storage limit for v2v-helper migration pods | `3Gi` | Kubernetes storage quantity |
|
||||
|
||||
## Modifying Settings
|
||||
|
||||
You can modify the ConfigMap to change settings using one of the following methods:
|
||||
|
||||
### Method 1: Edit with kubectl
|
||||
|
||||
```bash
|
||||
kubectl edit configmap vjailbreak-settings -n migration-system
|
||||
```
|
||||
|
||||
Then add or modify the data values as needed:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: vjailbreak-settings
|
||||
namespace: migration-system
|
||||
data:
|
||||
AUTO_FSTAB_UPDATE: "false"
|
||||
AUTO_PXE_BOOT_ON_CONVERSION: "false"
|
||||
CHANGED_BLOCKS_COPY_ITERATION_THRESHOLD: "30"
|
||||
CLEANUP_PORTS_AFTER_MIGRATION_FAILURE: "false"
|
||||
CLEANUP_VOLUMES_AFTER_CONVERT_FAILURE: "false"
|
||||
DEFAULT_MIGRATION_METHOD: "cold"
|
||||
DEPLOYMENT_NAME: "vJailbreak"
|
||||
OPENSTACK_CREDS_REQUEUE_AFTER_MINUTES: "60"
|
||||
PERIODIC_SYNC_INTERVAL: "1h"
|
||||
PERIODIC_SYNC_MAX_RETRIES: "3"
|
||||
PERIODIC_SYNC_RETRY_CAP: "3h"
|
||||
POPULATE_VMWARE_MACHINE_FLAVORS: "true"
|
||||
VALIDATE_RDM_OWNER_VMS: "true"
|
||||
VCENTER_LOGIN_RETRY_LIMIT: "5"
|
||||
VCENTER_SCAN_CONCURRENCY_LIMIT: "150"
|
||||
VM_ACTIVE_WAIT_INTERVAL_SECONDS: "30"
|
||||
VM_ACTIVE_WAIT_RETRY_LIMIT: "20"
|
||||
VMWARE_CREDS_REQUEUE_AFTER_MINUTES: "60"
|
||||
VOLUME_AVAILABLE_WAIT_INTERVAL_SECONDS: "10"
|
||||
VOLUME_AVAILABLE_WAIT_RETRY_LIMIT: "15"
|
||||
```
|
||||
|
||||
### Method 2: Using kubectl patch
|
||||
|
||||
You can modify individual settings without editing the entire ConfigMap:
|
||||
|
||||
```bash
|
||||
kubectl patch configmap -n migration-system vjailbreak-settings --type merge -p '{"data":{"VM_ACTIVE_WAIT_INTERVAL_SECONDS":"30","VM_ACTIVE_WAIT_RETRY_LIMIT":"20"}}'
|
||||
```
|
||||
|
||||
### Method 3: From a file
|
||||
|
||||
Create a file with your settings:
|
||||
|
||||
```bash
|
||||
cat > vjailbreak-settings.yaml << EOF
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: vjailbreak-settings
|
||||
namespace: migration-system
|
||||
data:
|
||||
AUTO_FSTAB_UPDATE: "false"
|
||||
AUTO_PXE_BOOT_ON_CONVERSION: "false"
|
||||
CHANGED_BLOCKS_COPY_ITERATION_THRESHOLD: "30"
|
||||
CLEANUP_PORTS_AFTER_MIGRATION_FAILURE: "false"
|
||||
CLEANUP_VOLUMES_AFTER_CONVERT_FAILURE: "false"
|
||||
DEFAULT_MIGRATION_METHOD: "cold"
|
||||
DEPLOYMENT_NAME: "vJailbreak"
|
||||
OPENSTACK_CREDS_REQUEUE_AFTER_MINUTES: "60"
|
||||
PERIODIC_SYNC_INTERVAL: "1h"
|
||||
PERIODIC_SYNC_MAX_RETRIES: "3"
|
||||
PERIODIC_SYNC_RETRY_CAP: "3h"
|
||||
POPULATE_VMWARE_MACHINE_FLAVORS: "true"
|
||||
VALIDATE_RDM_OWNER_VMS: "true"
|
||||
VCENTER_LOGIN_RETRY_LIMIT: "5"
|
||||
VCENTER_SCAN_CONCURRENCY_LIMIT: "150"
|
||||
VM_ACTIVE_WAIT_INTERVAL_SECONDS: "30"
|
||||
VM_ACTIVE_WAIT_RETRY_LIMIT: "20"
|
||||
VMWARE_CREDS_REQUEUE_AFTER_MINUTES: "60"
|
||||
VOLUME_AVAILABLE_WAIT_INTERVAL_SECONDS: "10"
|
||||
VOLUME_AVAILABLE_WAIT_RETRY_LIMIT: "15"
|
||||
EOF
|
||||
|
||||
kubectl apply -f vjailbreak-settings.yaml
|
||||
```
|
||||
|
||||
## Settings in Action
|
||||
|
||||
### Optimizing Block Copy Operations
|
||||
|
||||
To increase the number of iterations for copying changed blocks during hot migrations:
|
||||
|
||||
```bash
|
||||
kubectl patch configmap -n migration-system vjailbreak-settings --type merge -p '{"data":{"CHANGED_BLOCKS_COPY_ITERATION_THRESHOLD":"30"}}'
|
||||
```
|
||||
|
||||
### Adjusting VM Activation Parameters
|
||||
|
||||
To increase wait time and retry attempts for VM activation:
|
||||
|
||||
```bash
|
||||
kubectl patch configmap -n migration-system vjailbreak-settings --type merge -p '{"data":{"VM_ACTIVE_WAIT_INTERVAL_SECONDS":"30","VM_ACTIVE_WAIT_RETRY_LIMIT":"20"}}'
|
||||
```
|
||||
|
||||
### Optimizing Scan Performance
|
||||
|
||||
To increase the number of concurrent vCenter scan pods:
|
||||
|
||||
```bash
|
||||
kubectl patch configmap -n migration-system vjailbreak-settings --type merge -p '{"data":{"VCENTER_SCAN_CONCURRENCY_LIMIT":"150"}}'
|
||||
```
|
||||
|
||||
### Configuring Periodic Sync for Admin Cutover
|
||||
|
||||
To adjust the periodic sync settings for admin cutover migrations:
|
||||
|
||||
```bash
|
||||
kubectl patch configmap -n migration-system vjailbreak-settings --type merge -p '{"data":{"PERIODIC_SYNC_INTERVAL":"30m","PERIODIC_SYNC_MAX_RETRIES":"5","PERIODIC_SYNC_RETRY_CAP":"6h"}}'
|
||||
```
|
||||
|
||||
This configures the system to sync every 30 minutes, with a maximum of 5 retries, and a total retry window of 6 hours.
|
||||
|
||||
### Enabling Automatic Cleanup After Failures
|
||||
|
||||
To automatically cleanup resources after migration failures:
|
||||
|
||||
```bash
|
||||
kubectl patch configmap -n migration-system vjailbreak-settings --type merge -p '{"data":{"CLEANUP_PORTS_AFTER_MIGRATION_FAILURE":"true","CLEANUP_VOLUMES_AFTER_CONVERT_FAILURE":"true"}}'
|
||||
```
|
||||
|
||||
> **Note:** Enabling automatic cleanup helps prevent resource accumulation after failed migrations, but ensure you have proper logging and monitoring in place to track what gets cleaned up.
|
||||
|
||||
### Adjusting Volume Availability Wait Parameters
|
||||
|
||||
To increase wait time and retry attempts for volumes to become available:
|
||||
|
||||
```bash
|
||||
kubectl patch configmap -n migration-system vjailbreak-settings --type merge -p '{"data":{"VOLUME_AVAILABLE_WAIT_INTERVAL_SECONDS":"15","VOLUME_AVAILABLE_WAIT_RETRY_LIMIT":"20"}}'
|
||||
```
|
||||
|
||||
### Configuring Credentials Revalidation Intervals
|
||||
|
||||
To adjust how frequently credentials are revalidated:
|
||||
|
||||
```bash
|
||||
kubectl patch configmap -n migration-system vjailbreak-settings --type merge -p '{"data":{"OPENSTACK_CREDS_REQUEUE_AFTER_MINUTES":"30","VMWARE_CREDS_REQUEUE_AFTER_MINUTES":"30"}}'
|
||||
```
|
||||
|
||||
### Configuring RDM Disk Validation
|
||||
|
||||
To disable the validation that requires all VMs linked to an RDM disk to be migrated in a single migration plan:
|
||||
|
||||
```bash
|
||||
kubectl patch configmap -n migration-system vjailbreak-settings --type merge -p '{"data":{"VALIDATE_RDM_OWNER_VMS":"false"}}'
|
||||
```
|
||||
|
||||
> **Note:** When `VALIDATE_RDM_OWNER_VMS` is set to `true` (default), the system ensures that all VMs sharing an RDM disk are migrated together in the same migration plan. This prevents potential data consistency issues. Only disable this validation if you understand the implications for your RDM disk configuration.
|
||||
|
||||
### Setting Default Migration Method
|
||||
|
||||
To set the default migration method for VMs:
|
||||
|
||||
```bash
|
||||
kubectl patch configmap -n migration-system vjailbreak-settings --type merge -p '{"data":{"DEFAULT_MIGRATION_METHOD":"hot"}}'
|
||||
```
|
||||
|
||||
The system supports two migration methods:
|
||||
|
||||
- **Hot migration**: Migrates VMs while they are running, minimizing downtime but requiring more coordination and potentially multiple sync iterations to capture changed blocks
|
||||
- **Cold migration** (default): Powers off the VM before migration, ensuring data consistency but causing downtime during the entire migration process
|
||||
|
||||
## Verification
|
||||
|
||||
To verify your settings have been applied correctly:
|
||||
|
||||
```bash
|
||||
kubectl get configmap -n migration-system vjailbreak-settings -o yaml
|
||||
```
|
||||
|
||||
## Applying Changes
|
||||
|
||||
After modifying settings in the ConfigMap, the behavior depends on which settings you changed:
|
||||
|
||||
### Settings That Require Controller Restart
|
||||
|
||||
The following settings are loaded at controller startup and require a restart of the migration controller pod to take effect:
|
||||
|
||||
- `OPENSTACK_CREDS_REQUEUE_AFTER_MINUTES`
|
||||
- `VMWARE_CREDS_REQUEUE_AFTER_MINUTES`
|
||||
|
||||
To restart the controller after changing these settings:
|
||||
|
||||
```bash
|
||||
kubectl rollout restart deployment migration-controller-manager -n migration-system
|
||||
```
|
||||
|
||||
### Settings That Take Effect Immediately
|
||||
|
||||
All other settings are read dynamically at runtime and do not require a restart:
|
||||
|
||||
- `AUTO_FSTAB_UPDATE`
|
||||
- `AUTO_PXE_BOOT_ON_CONVERSION`
|
||||
- `CHANGED_BLOCKS_COPY_ITERATION_THRESHOLD`
|
||||
- `CLEANUP_PORTS_AFTER_MIGRATION_FAILURE`
|
||||
- `CLEANUP_VOLUMES_AFTER_CONVERT_FAILURE`
|
||||
- `DEFAULT_MIGRATION_METHOD`
|
||||
- `DEPLOYMENT_NAME`
|
||||
- `PERIODIC_SYNC_INTERVAL`
|
||||
- `PERIODIC_SYNC_MAX_RETRIES`
|
||||
- `PERIODIC_SYNC_RETRY_CAP`
|
||||
- `POPULATE_VMWARE_MACHINE_FLAVORS`
|
||||
- `VALIDATE_RDM_OWNER_VMS`
|
||||
- `VCENTER_LOGIN_RETRY_LIMIT`
|
||||
- `VCENTER_SCAN_CONCURRENCY_LIMIT`
|
||||
- `VM_ACTIVE_WAIT_INTERVAL_SECONDS`
|
||||
- `VM_ACTIVE_WAIT_RETRY_LIMIT`
|
||||
- `VOLUME_AVAILABLE_WAIT_INTERVAL_SECONDS`
|
||||
- `VOLUME_AVAILABLE_WAIT_RETRY_LIMIT`
|
||||
|
||||
### When Changes Take Effect
|
||||
|
||||
For settings that don't require restart:
|
||||
|
||||
- **On-demand access**: Values are read from the ConfigMap when they are needed for an operation
|
||||
- **New operations**: Changes affect only new operations that start after the ConfigMap is updated
|
||||
- **In-progress operations**: Running operations continue using the values they initially read
|
||||
- **No caching**: The system does not cache these values for extended periods, ensuring relatively quick propagation of changes
|
||||
|
||||
Typically, your changes will be effective within seconds for any new operations initiated after updating the ConfigMap.
|
||||
|
||||
## Best Practices and Considerations
|
||||
|
||||
### Testing Recommendations
|
||||
- Always test configuration changes in a test environment that closely matches your production setup before applying them to production.
|
||||
- Validate each setting change independently to understand its impact on system behavior.
|
||||
- Document any changes made to default settings for future reference and troubleshooting.
|
||||
|
||||
### Operational Considerations
|
||||
- Setting changes take effect for new operations and do not affect in-progress tasks.
|
||||
- The impact of settings varies based on your specific environment (hardware, network, storage configuration).
|
||||
- Performance-related settings should be adjusted based on your specific infrastructure capabilities.
|
||||
|
||||
### Monitoring and Validation
|
||||
- After changing settings, monitor system behavior to ensure the changes produce the expected results.
|
||||
- Use vJailbreak logs to verify that settings are being correctly applied.
|
||||
|
||||
> **Important:** Always select configuration values appropriate for your specific environment. Incorrect settings may negatively impact system performance or stability.
|
||||
@@ -0,0 +1,113 @@
|
||||
---
|
||||
title: Virtual Trusted Platform Module (vTPM) VM Migration
|
||||
description: Guide for migrating Windows VMs with vTPM and Virtualization Based Security (VBS) enabled
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
While Virtualization Based Security (VBS) and Virtual Trusted Platform Module (vTPM) provide important security protections for the VM, V2V helpers and guestfs require proper read and write access to the VM's disks. Temporarily disabling these features ensures that migration and disk operations can proceed reliably.
|
||||
|
||||
:::caution
|
||||
Windows 11 with vTPM requires an account for login to the VM. Users may need to reset their PIN after disabling vTPM. Ensure you have a **backup email configured** to reset the PIN or recover the password post migration.
|
||||
:::
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- **VMware Native Key Provider** (default vCenter-level key provider) must be configured for enabling vTPM on the source VM.
|
||||
- On PCD, use `tpm_version: 2.0` and `tpm_provider: tpm-crb` as extra metadata specs on the VM flavor to enable vTPM post migration.
|
||||
|
||||
|
||||
|
||||
## Enabling VBS and vTPM During Windows 11 Installation
|
||||
|
||||
When installing Windows 11, the user can enable VBS and vTPM at the OS selection stage by checking **"Enable Windows Virtualization Based Security"**.
|
||||
|
||||
|
||||
|
||||
On the next stage (Customize hardware), you can verify that the **Trusted Platform Module** is present under **Security Devices**.
|
||||
|
||||
|
||||
|
||||
## Pre-Migration Steps
|
||||
|
||||
### Step 1: Power Off the Guest OS
|
||||
|
||||
Power off the guest OS on vCenter so that you can edit the VM settings and disable VBS and vTPM.
|
||||
|
||||
### Step 2: Disable Virtualization Based Security
|
||||
|
||||
1. Right-click the VM in vCenter and select **Edit Settings**.
|
||||
2. Navigate to the **VM Options** tab.
|
||||
3. Expand **Virtualization Based Security** and **uncheck** the **Enable** checkbox.
|
||||
4. Click **OK** to save.
|
||||
|
||||
|
||||
|
||||
### Step 3: Change VM Encryption Policies
|
||||
|
||||
Change the encryption policies of the VM to the **Datastore Default** policy:
|
||||
|
||||
1. Right-click the VM in vCenter.
|
||||
2. Go to **VM Policies → Edit VM Storage Policies**.
|
||||
3. Set the VM storage policy to **Datastore Default**.
|
||||
4. Click **OK** to apply.
|
||||
|
||||
|
||||
|
||||
|
||||
### Step 4: Remove vTPM Device
|
||||
|
||||
1. Right-click the VM in vCenter and select **Edit Settings**.
|
||||
2. Under **Security Devices**, locate the **Virtual TPM** device.
|
||||
3. Remove the vTPM device and confirm the deletion when prompted.
|
||||
|
||||
:::caution
|
||||
Removing TPM will render all encrypted data on this VM unrecoverable. Ensure you have proper backups before proceeding.
|
||||
:::
|
||||
|
||||
|
||||
|
||||
## Start Migration
|
||||
|
||||
With VBS disabled, encryption policies reset, and the vTPM device removed, proceed with the migration using vJailbreak as usual.
|
||||
|
||||
|
||||
|
||||
## Post-Migration Steps
|
||||
|
||||
After the migration completes successfully, re-enable vTPM on the VM in PCD by following the steps below.
|
||||
|
||||
### Step 1: Reset PIN Using Backup Email
|
||||
|
||||
Since vTPM was removed before migration, the user will need to reset their PIN using the backup email configured earlier.
|
||||
|
||||
### Step 2: Create a New Flavor with TPM Metadata
|
||||
|
||||
Create a new flavor (or update an existing one) with the same size as the migrated VM, adding the following TPM metadata:
|
||||
|
||||
| Key | Value |
|
||||
|-----------------|----------|
|
||||
| `hw:tpm_model` | `tpm-crb`|
|
||||
| `hw:tpm_version`| `2.0` |
|
||||
|
||||
|
||||
|
||||
### Step 3: Resize Migrated VM Using the TPM Flavor
|
||||
|
||||
1. Navigate to the migrated VM in PCD.
|
||||
2. Resize the VM using the newly created flavor with TPM metadata.
|
||||
3. Confirm the resize operation.
|
||||
|
||||
|
||||
|
||||
### Step 4: Verify TPM is Enabled
|
||||
|
||||
After the resize completes, verify that TPM is enabled on the VM:
|
||||
|
||||
- **From the hypervisor**: Run `virsh dumpxml <instance> | grep -i tpm` to confirm the `<tpm model='tpm-crb'>` block is present in the VM's XML definition.
|
||||
|
||||
|
||||
|
||||
- **From inside the VM**: Open **TPM Management** (`tpm.msc`) and verify that the TPM status shows **"The TPM is ready for use."**
|
||||
|
||||
|
||||
@@ -0,0 +1,205 @@
|
||||
---
|
||||
title: "Windows Dynamic Disk (LDM) Migration"
|
||||
description: "Migrate Windows VMs whose system volume is on a dynamic disk (LDM), including the prerequisites and the LDM Boot Verification cutover."
|
||||
---
|
||||
|
||||
Windows VMs whose **system volume sits on a dynamic disk (LDM)** follow a different
|
||||
migration path. `virt-v2v` cannot convert these guests, so vJailbreak brings the VM
|
||||
up on an emulated SATA controller first and lets you move it to virtio once you have
|
||||
confirmed it boots.
|
||||
|
||||
vJailbreak detects this automatically during the migration, but you have to prepare the source VM for such VMs. There is nothing to select in the migration form.
|
||||
form.
|
||||
|
||||
:::note[Only the system volume matters]
|
||||
If just the **data disks** are dynamic, none of this applies. The VM migrates
|
||||
normally, with conversion and every post-migration step running as usual.
|
||||
:::
|
||||
|
||||
Because conversion is skipped, these do not run for LDM guests: **VMware Tools
|
||||
removal**, **network persistence** and **user firstboot scripts**. That is why the
|
||||
tasks below are manual.
|
||||
|
||||
## 1. Before you start
|
||||
|
||||
vJailbreak detects LDM on its own, but if you want to know in advance which VMs
|
||||
will take this path, run the precheck script on the source VM as Administrator. It
|
||||
is read-only, prints a plain **YES** or **NO**, and writes a transcript to
|
||||
`%TEMP%\vjb-ldm-check.log`.
|
||||
|
||||
<a href="../../../scripts/Test-VjbLdmSystemDisk.ps1" download>Download Test-VjbLdmSystemDisk.ps1</a>
|
||||
|
||||
```powershell
|
||||
powershell -ExecutionPolicy Bypass -File .\Test-VjbLdmSystemDisk.ps1
|
||||
```
|
||||
|
||||
It also sets an exit code — `1` for LDM, `0` for basic, `2` if inconclusive — so it
|
||||
can be run across a fleet to build the list of VMs that need the steps below.
|
||||
|
||||
**Take a snapshot of the source VM in vCenter before making any of the changes
|
||||
below.** Both steps modify the guest, and the driver installation requires a
|
||||
reboot. The snapshot is your way back if either one leaves the VM in a state you
|
||||
did not intend.
|
||||
|
||||
Both tasks below are performed on the source VM in vCenter, while it is still
|
||||
running on ESXi, as Administrator.
|
||||
|
||||
### Install the VirtIO drivers
|
||||
|
||||
1. **Download the ISO.** Every build is published in the
|
||||
[virtio-win archive](https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/).
|
||||
Windows Server 2016 and later can use the current build.
|
||||
|
||||
:::caution
|
||||
**Windows Server 2012 and 2012 R2 must use `virtio-win-0.1.185.iso`**, in the
|
||||
`virtio-win-0.1.185-1` folder. Later builds dropped support for these versions
|
||||
and leave the guest without a usable storage driver.
|
||||
:::
|
||||
|
||||
2. **Upload the ISO** to a datastore the ESXi host can reach.
|
||||
|
||||
3. **Attach it to the VM.** In vCenter, right-click the VM → **Edit Settings** →
|
||||
**CD/DVD drive 1** → **Datastore ISO File**, browse to the ISO, and tick
|
||||
**Connected**.
|
||||
|
||||
4. **Run the installer in the guest.** Open File Explorer, open the mounted CD
|
||||
drive, and run **`virtio-win-guest-tools.exe`**.
|
||||
|
||||
5. **Click through the wizard**, accepting the defaults, and finish it.
|
||||
|
||||
6. **Reboot the VM**, then disconnect the ISO.
|
||||
|
||||
Nothing will look different afterwards — there is no virtio device in vCenter yet,
|
||||
so the drivers sit staged until one appears at the destination.
|
||||
|
||||
### Set the SAN policy
|
||||
|
||||
Windows marks migrated disks offline because the controller changed; skipping this
|
||||
leaves the LDM pool broken.
|
||||
|
||||
```
|
||||
diskpart
|
||||
san policy=onlineall
|
||||
exit
|
||||
```
|
||||
|
||||
## 2. Trigger the migration
|
||||
|
||||
Start the migration as usual. vJailbreak skips conversion, creates the VM with
|
||||
`hw_disk_bus: sata`, and attaches a **1 GB virtio temporary disk**. Windows performs
|
||||
a real driver installation against that device on first boot, which is what gets the
|
||||
VirtIO storage driver installed and bound — offline injection cannot do this. The
|
||||
temporary disk is removed later.
|
||||
|
||||
The status of the migration then changes to **LDM Boot Verification**, and the
|
||||
migration waits for you to perform the cutover.
|
||||
|
||||
## 3. Confirm the VM booted
|
||||
|
||||
Open the console of the new VM in PCD and log in. What you should check inside the guest is that
|
||||
Windows bound a VirtIO driver to the temporary disk — if it did, the root disk will work
|
||||
on virtio too. Below are the commands to check that.
|
||||
|
||||
**Run these before performing the cutover.** The temporary disk only exists while the
|
||||
migration is held at **LDM Boot Verification**; it is removed whichever option you
|
||||
select, so the output changes afterwards.
|
||||
|
||||
```powershell
|
||||
# The 1 GB temporary disk must be present, with VirtIO in its model name.
|
||||
Get-WmiObject Win32_DiskDrive | Select-Object Model, Size
|
||||
|
||||
# The controller must be healthy.
|
||||
Get-WmiObject Win32_PnPEntity | Where-Object { $_.Name -like '*VirtIO*' } |
|
||||
Select-Object Name, Status
|
||||
```
|
||||
|
||||
Expect a disk of roughly 1 GB whose model names VirtIO, and a controller reporting
|
||||
`OK`. Device Manager shows the same thing under **Storage controllers**. Both
|
||||
commands work on every supported Windows version, including Server 2012.
|
||||
|
||||
:::caution[Do not use `sc query viostor`]
|
||||
On a VM booted from SATA this reports `STOPPED` even when the driver is installed
|
||||
and working, so it will make a healthy VM look broken. The service state of a
|
||||
storage miniport is not a reliable signal here — check for the device, as above.
|
||||
:::
|
||||
|
||||
If you re-run the same commands after the cutover, expect different output.
|
||||
|
||||
Once above is verified, you will have 3 cutover options:
|
||||
|
||||
| Cutover option | What the checks show afterwards |
|
||||
| --- | --- |
|
||||
| **Move to virtio** | The temporary disk is gone and the **root** disk now reports a VirtIO model. This is the successful end state. |
|
||||
| **Keep on SATA** | The temporary disk is gone and no VirtIO disk remains, because the root disk stayed on SATA. A VirtIO controller may linger in Device Manager as a non-present device. Expected — not a failure. |
|
||||
| **Rollback Migration** | The VM no longer exists in PCD. |
|
||||
|
||||
## 4. Perform the cutover
|
||||
|
||||
There is no timeout. The migration remains at **LDM Boot Verification** until the
|
||||
cutover is performed, so it can be scheduled for a maintenance window.
|
||||
|
||||
### Cutover from the UI
|
||||
|
||||
Click the cutover button on the migration, either in the migrations table or on the
|
||||
migration details page. A confirmation dialog appears with three options:
|
||||
|
||||
| Choice | Result |
|
||||
| --- | --- |
|
||||
| **Move to virtio** | The VM is shut down, deleted and recreated with the root disk on virtio, keeping its name, IP and MAC. |
|
||||
| **Keep on SATA** | The migration completes with the VM disk left on SATA. |
|
||||
| **Rollback Migration** | The VM is deleted from PCD and the source VM in vCenter is returned to its pre-migration state. |
|
||||
|
||||
**Leave the VM running** — the shutdown is handled for you. Expect a short outage
|
||||
while it is recreated; the phase shows **Moving to virtio** during the rebuild.
|
||||
|
||||
If the checks in step 3 did not pass, select **Keep on SATA**. The VM remains fully
|
||||
functional on the SATA controller; only the performance benefit of virtio is lost.
|
||||
Select **Rollback Migration** only if the VM did not boot at all.
|
||||
|
||||
### Cutover using kubectl patch
|
||||
|
||||
The cutover can also be performed by patching the migration `Pod`.
|
||||
|
||||
```bash
|
||||
kubectl get migration <migration-name> -n migration-system -o jsonpath='{.spec.podRef}'
|
||||
|
||||
kubectl patch pod <pod-name> -n migration-system \
|
||||
-p '{"metadata":{"labels":{"ldmBootStatus":"success"}}}'
|
||||
```
|
||||
|
||||
| Label value | Equivalent option |
|
||||
| --- | --- |
|
||||
| `success` | Move to virtio |
|
||||
| `finish` | Keep on SATA |
|
||||
| `failed` | Rollback Migration |
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Disks show "Failed Redundancy"
|
||||
|
||||
Seen on mirrored LDM volumes when the SAN policy was not set beforehand. Windows
|
||||
marked a disk offline, so the mirror ran on one plex; by the time the disk returned,
|
||||
the copies had diverged and LDM refuses to merge them.
|
||||
|
||||
Confirm which disk is stale with `detail volume` or Disk Management, then:
|
||||
|
||||
```
|
||||
diskpart> san policy=onlineall
|
||||
Set-Disk -Number 2 -IsOffline $false
|
||||
diskpart> select volume 0 ; online volume
|
||||
diskpart> select volume 0 ; break disk=2 nokeep
|
||||
diskpart> select volume 0 ; add disk=2
|
||||
```
|
||||
|
||||
:::danger
|
||||
`break ... nokeep` deletes the named disk's plex. Confirm the disk number first —
|
||||
breaking the **live** disk destroys the copy the VM has been running from.
|
||||
:::
|
||||
|
||||
No data is lost when the correct disk is named. There is no redundancy while the
|
||||
mirror resyncs, but the window is bounded.
|
||||
|
||||
### The VM did not boot on SATA
|
||||
|
||||
Perform the cutover with **Rollback Migration**, correct the prerequisites, and
|
||||
migrate again.
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "Debug vJailbreak Installation"
|
||||
description: "Learn how to debug installation issues related to vJailbreak, including where the install script is located, how it works, and what to check when things go wrong."
|
||||
---
|
||||
|
||||
### 1. Check Installation Logs
|
||||
|
||||
All logs related to the install process are written to:
|
||||
|
||||
`/var/log/pf9-install.log`
|
||||
|
||||
Look here for:
|
||||
- Image pull errors
|
||||
- Authentication issues
|
||||
- YAML apply failures
|
||||
- Proxy or network errors
|
||||
|
||||
> 🔍 **Tip:** If you're seeing errors related to pulling images, verify that the image registry URL is accessible from within the vJailbreak VM.
|
||||
|
||||
---
|
||||
|
||||
### 2. Test Registry Access (Image Pull Failures)
|
||||
|
||||
If the logs show image pull issues, run this on the vJailbreak VM:
|
||||
|
||||
```bash
|
||||
curl -v <image-url>
|
||||
```
|
||||
|
||||
🔁 What If the URL Is Accessible but Installation Still Fails?
|
||||
Even if the URL is accessible, transient network issues or Kubernetes API hiccups might cause failures.
|
||||
|
||||
Recheck /var/log/pf9-install.log for intermittent or recoverable errors.
|
||||
|
||||
In such cases, you can safely re-run the installer:
|
||||
|
||||
```bash
|
||||
sudo bash /etc/pf9/install.sh
|
||||
```
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "Debug Logs"
|
||||
description: "Learn how vJailbreak collects and stores migration debug logs directly on the host, and how to download a full debug bundle from the UI."
|
||||
---
|
||||
|
||||
|
||||
This guide outlines how vJailbreak handles debug log collection for VM migrations. Traditionally, enabling debug logs required editing ConfigMaps and restarting pods. With the current setup, debug logs are automatically collected and stored without any manual intervention. In kubectl logs of the pod, normal logs will be displayed as usual.
|
||||
|
||||
## How It Works
|
||||
|
||||
- For every migration executed via vJailbreak, debug logs are written to the host system under `/var/log/pf9`.
|
||||
- A high-level milestone log is written for the migration at:
|
||||
|
||||
`/var/log/pf9/<migration-name>.log`
|
||||
|
||||
This mirrors the same key milestone messages (e.g. "Snapshot created", "Starting NBD server", "VM active") that also appear in `kubectl logs` for the pod — it is not a full copy of the pod's stdout/stderr.
|
||||
|
||||
- In addition, logs are now **split by category** into a dedicated directory for the migration:
|
||||
|
||||
`/var/log/pf9/<migration-name>/<category>.<timestamp>.log`
|
||||
|
||||
Each category captures the output of a specific part of the migration, so an issue can be traced straight to the relevant subsystem instead of scanning one milestone log:
|
||||
|
||||
| Category | Contents |
|
||||
|-----------|-------------------------------------------------------|
|
||||
| `nbd` | NBD/`nbdcopy` disk-copy commands and their output |
|
||||
| `virtv2v` | `virt-v2v` conversion commands and their output |
|
||||
| `general` | Everything else run during the migration |
|
||||
|
||||
- These logs are centrally accessible from the **vjailbreak node**, simplifying the debugging process.
|
||||
|
||||
## Log File Location
|
||||
|
||||
| Node Type | Path | Description |
|
||||
|--------------------|----------------------------------------------------|-------------------------------------------------------|
|
||||
| vjailbreak-master | `/var/log/pf9/<migration>.log` | High-level milestone log for the migration |
|
||||
| vjailbreak-master | `/var/log/pf9/<migration>/<category>.<timestamp>.log` | Per-category split logs (`nbd`, `virtv2v`, `general`) |
|
||||
|
||||
## Example
|
||||
|
||||
If a migration is named `vm-migrate-001`, its logs will be available at:
|
||||
|
||||
- `/var/log/pf9/vm-migrate-001.log` — milestone log
|
||||
- `/var/log/pf9/vm-migrate-001/nbd.2026-08-25-10:15:00.log` — disk-copy log
|
||||
- `/var/log/pf9/vm-migrate-001/virtv2v.2026-08-25-10:20:00.log` — conversion log
|
||||
|
||||
on the vjailbreak node.
|
||||
|
||||
## Downloading a Debug Bundle from the UI
|
||||
|
||||
Instead of SSHing into the vjailbreak node to collect logs manually, you can download a full debug bundle directly from the migration's **Pod logs** tab.
|
||||
|
||||
|
||||
|
||||
There is a download button as shown in the image above. This downloads all the logs, debug logs, and everything related to the migration as a tar ball — no extra `kubectl` or SSH access is required.
|
||||
+49
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: nbdcopy fails during disk copy (often DNS resolution)
|
||||
description: Troubleshooting disk copy failures caused by missing DNS/hosts entries
|
||||
---
|
||||
|
||||
## Problem
|
||||
|
||||
A migration fails during the disk copy (live replicate) phase with an error similar to:
|
||||
|
||||
```text
|
||||
Failed to migrate VM: failed to live replicate disks: failed to copy disk Hard disk 1 (DeviceKey=2000): failed to run nbdcopy: exec: already started.
|
||||
```
|
||||
|
||||
Error signature:
|
||||
```text
|
||||
failed to run nbdcopy: exec: already started
|
||||
```
|
||||
|
||||
## Symptoms
|
||||
|
||||
- Migration fails during the **nbdcopy** phase.
|
||||
- Debug logs often show **DNS resolution errors** when attempting to connect to an ESXi host.
|
||||
|
||||
## Root Cause
|
||||
|
||||
During the disk copy phase, vJailbreak needs to communicate with ESXi hosts. If name resolution for an ESXi host is not available from the vJailbreak VM, the nbdcopy workflow can fail.
|
||||
|
||||
This is commonly caused by missing DNS records or missing `/etc/hosts` entries for ESXi hosts.
|
||||
|
||||
## Resolution
|
||||
|
||||
1. Review the debug logs to confirm DNS/name-resolution errors.
|
||||
|
||||
See: [Debug Logs](../debuglogs/).
|
||||
|
||||
2. Ensure the vJailbreak VM can resolve ESXi host names.
|
||||
|
||||
If you are not using DNS, add a static entry on the vJailbreak VM:
|
||||
|
||||
```bash
|
||||
sudo sh -c 'echo "<esxi-host-ip> <esxi-host-fqdn> <esxi-host-shortname>" >> /etc/hosts'
|
||||
```
|
||||
|
||||
3. Re-run the migration.
|
||||
|
||||
## Prevention
|
||||
|
||||
- Ensure DNS (or `/etc/hosts`) is configured for **all ESXi hosts** in the cluster, not just vCenter.
|
||||
|
||||
@@ -0,0 +1,290 @@
|
||||
---
|
||||
title: Troubleshooting vJailbreak
|
||||
description: Tips on effectively troubleshooting vJailbreak deployment and migration
|
||||
---
|
||||
|
||||
:::note
|
||||
All of the following Kubernetes commands will need to be run from the vJailbreak VM, or remotely using the vJailbreak VM's kubeconfig, located at `/etc/ranger/k3s/k3s.yaml` on the vJailbreak VM.
|
||||
:::
|
||||
|
||||
## Common issues
|
||||
|
||||
- [VDDK unavailable: VMware's public download pages are down](#vddk-unavailable-vmwares-public-download-pages-are-down)
|
||||
- [Windows Dynamic Disk (LDM) migration](../../how-to/windows-ldm-migration/)
|
||||
- [nbdcopy fails during disk copy (often DNS resolution)](nbdcopy-fails-after-vm-moved-esxi-host/)
|
||||
- [virt-v2v fails: rename /sysroot/etc/resolv.conf Operation not permitted](#virt-v2v-fails-rename-sysrootetcresolvconf-operation-not-permitted)
|
||||
- [virt-v2v-in-place fails on RHEL 7: missing GRUB compatibility symlink](#virt-v2v-in-place-fails-on-rhel-7-missing-grub-compatibility-symlink)
|
||||
- [Proxy VM disk attach fails when several migrations start together](#proxy-vm-disk-attach-fails-when-several-migrations-start-together)
|
||||
- [vJailbreak Accelerated Copy fails: could not identify block device](#vjailbreak-accelerated-copy-fails-could-not-identify-block-device)
|
||||
|
||||
vJailbreak is deployed on Kubernetes running on Ubuntu 22.04.5, and distributed as a QCOW2 image. The Kubernetes namespace `migration-system` contains the vJailbreak UI and migration controller pods. Each VM migration will spawn a migration object. The status field contains a high level view of the progress of the migration of the VM. For more details about the migration, check the logs of the pod specified in the Migration object.
|
||||
|
||||
### Getting logs
|
||||
List all pods in the migration namespace
|
||||
```bash
|
||||
kubectl -n migration-system get pod
|
||||
```
|
||||
|
||||
Find a specific VM migration pod
|
||||
```bash
|
||||
kubectl -n migration-system get pod | grep <source VM name>
|
||||
```
|
||||
|
||||
Get details & events for a v2v-helper pod. This is helpful if a migration is stuck in a pending state, or to track the progress of a migration without the UI.
|
||||
```bash
|
||||
kubectl -n migration-system describe pod <v2v-helper-pod-name>
|
||||
```
|
||||
|
||||
Get logs for a specific migration pod. This shows more detail than `describe pod`.
|
||||
```bash
|
||||
kubectl logs <pod> -n migration-system
|
||||
```
|
||||
|
||||
Get logs for the `migration-controller-manager`
|
||||
```bash
|
||||
kubectl logs -n migration-system deploy/migration-controller-manager
|
||||
```
|
||||
|
||||
Turn on Debug Mode
|
||||
```bash
|
||||
kubectl patch configmap -n migration-system migration-config-<vm-name> --type merge -p '{"data":{"DEBUG":"true"}}'
|
||||
```
|
||||
### A migration is stuck in pending
|
||||
If the migration was set to Retry on Failure, then delete the v2v-helper pod for that VM and collect the logs of the pod that comes up.
|
||||
|
||||
```bash
|
||||
kubectl delete pod -n migration-system v2v-helper-<vm-name>
|
||||
```
|
||||
If the v2v-helper pod doesn't come back up, and you can't delete the migration in the UI, then delete the associated `migrationplan`.
|
||||
- First, get the `migrationplan` object name UUID for the associated VMs:
|
||||
```bash
|
||||
kubectl get migrationplans -n migration-system -o yaml
|
||||
```
|
||||
- Then delete the `migrationplan` object, which should remove it from the UI.
|
||||
```bash
|
||||
kubectl delete migrationplan <UUID> -n migration-system
|
||||
```
|
||||
### A migration failed and I want to run it again
|
||||
Use the **Retry** action on the failed migration in the vJailbreak UI. It reopens the migration form pre-filled with the original configuration, so you can correct the setting that caused the failure before starting again. To restart several failed migrations without changing anything, select them in the **Migrations** table and use **Retry Selected**.
|
||||
|
||||
See [Retry a Failed Migration](../how-to/retry_failed_migration/) for the full workflow and its limitations.
|
||||
|
||||
### Get all vJailbreak custom resource definitions (CRDs)
|
||||
|
||||
```bash
|
||||
kubectl get migrationplans,migrations,migrationtemplates,networkmappings,openstackcreds,storagemappings,vmwarecreds,secrets -n migration-system -o yaml
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## virt-v2v fails: rename /sysroot/etc/resolv.conf Operation not permitted
|
||||
|
||||
- **Symptom**
|
||||
|
||||
`virt-v2v` or `virt-v2v-in-place` fails with an error similar to:
|
||||
|
||||
```text
|
||||
renaming /sysroot/etc/resolv.conf to /sysroot/etc/6vvk9gzd
|
||||
guestfsd: error: rename: /sysroot/etc/resolv.conf to /sysroot/etc/6vvk9gzd: Operation not permitted
|
||||
commandrvf: stdout=n stderr=n flags=0x0
|
||||
commandrvf: umount /sysroot/sys
|
||||
virt-v2v-in-place: error: libguestfs error: sh_out: rename: /sysroot/etc/resolv.conf to /sysroot/etc/6vvk9gzd: Operation not permitted
|
||||
```
|
||||
|
||||
- **Cause**
|
||||
|
||||
On some Linux VMs, `/etc/resolv.conf` is marked **immutable**. When `virt-v2v` tries to rename or replace this file inside the guest filesystem during conversion, the immutable attribute prevents the operation and conversion fails.
|
||||
|
||||
You can confirm the immutable bit inside the source VM with:
|
||||
|
||||
```bash
|
||||
lsattr /etc/resolv.conf
|
||||
----i----------------- /etc/resolv.conf
|
||||
```
|
||||
|
||||
The `i` flag indicates the file is immutable.
|
||||
|
||||
- **Resolution**
|
||||
|
||||
1. Remove the immutable attribute inside the source VM before migration:
|
||||
|
||||
```bash
|
||||
chattr -i /etc/resolv.conf
|
||||
```
|
||||
|
||||
2. Verify the attribute is gone:
|
||||
|
||||
```bash
|
||||
lsattr /etc/resolv.conf
|
||||
---------------------- /etc/resolv.conf
|
||||
```
|
||||
|
||||
3. Re-run the migration.
|
||||
|
||||
- **Notes**
|
||||
|
||||
- This is a known and documented `virt-v2v` issue. [See upstream documentation](https://libguestfs.org/virt-v2v.1.html#linux%3A-rename%3A-sysroot-etc-resolv.conf-failure).
|
||||
- If configuration management or security hardening marks `/etc/resolv.conf` immutable, ensure this is unset before conversion, or adjust your automation so VMs intended for conversion do not have `/etc/resolv.conf` marked immutable.
|
||||
|
||||
---
|
||||
|
||||
## Disk attach fails during migration: No more available PCI slots
|
||||
|
||||
- **Symptom**
|
||||
|
||||
During a migration, attaching a target volume to the vJailbreak VM (or an agent VM) fails. The `nova-compute` log on the OpenStack side shows an error similar to:
|
||||
|
||||
```text
|
||||
TRACE nova.virt.libvirt.driver [instance: <uuid>] libvirt.libvirtError: internal error: No more available PCI slots
|
||||
```
|
||||
|
||||
- **Cause**
|
||||
|
||||
During conversion, vJailbreak attaches the target Cinder volumes to the vJailbreak VM (or its agent VMs) to copy and convert the disk data. If the vJailbreak image was uploaded without a disk bus setting, OpenStack attaches these volumes using the default **virtio-blk** bus, where **every attached volume is a separate PCI device** and consumes its own PCI slot.
|
||||
|
||||
The virtual PCI bus has a limited number of slots, several of which are already used by essential devices (network interfaces, video, memory balloon, and so on). Migrating VMs with many disks — or running many migrations in parallel on one agent — exhausts the available PCI slots, and the volume attach fails with the error above.
|
||||
|
||||
- **Resolution**
|
||||
|
||||
Configure the vJailbreak image to use the **virtio-scsi** disk bus. With virtio-scsi, all attached volumes share a single SCSI controller that consumes only one PCI slot and supports up to 256 devices.
|
||||
|
||||
1. Set the following properties on the vJailbreak image **before** creating the vJailbreak VM:
|
||||
|
||||
```bash
|
||||
openstack image set \
|
||||
--property hw_disk_bus=scsi \
|
||||
--property hw_scsi_model=virtio-scsi \
|
||||
<vjailbreak-image-name-or-ID>
|
||||
```
|
||||
|
||||
2. Deploy the vJailbreak VM from the updated image, then re-run the migration.
|
||||
|
||||
- **Notes**
|
||||
|
||||
- The disk bus is fixed when the VM is created. If your vJailbreak VM is already deployed, setting the properties on the image is not enough — you must recreate the vJailbreak VM from the updated image.
|
||||
- Agent VMs created during [scale up](../../how-to/scaling/) use the same image, so set these properties before scaling up agents.
|
||||
- See also: [Known Limitations](../../../reference/known-limitations/#pci-slot-exhaustion-when-attaching-disks-with-virtio-blk).
|
||||
|
||||
---
|
||||
|
||||
## virt-v2v-in-place fails on RHEL 7: missing GRUB compatibility symlink
|
||||
|
||||
- **Symptom**
|
||||
|
||||
A RHEL 7.x migration fails during `virt-v2v-in-place`, after disk copy and volume attach/detach have already succeeded. The migration log only shows:
|
||||
|
||||
```text
|
||||
failed to run virt-v2v-in-place: exit status 1
|
||||
```
|
||||
|
||||
The debug log under `/var/log/pf9/` (see [Debug Logs](debuglogs/)) shows the actual error:
|
||||
|
||||
```text
|
||||
virt-v2v-in-place: error: libguestfs error: command:
|
||||
error opening /boot/grub/grub.cfg for read:
|
||||
No such file or directory
|
||||
```
|
||||
|
||||
- **Cause**
|
||||
|
||||
RHEL 7's `grubby`, used internally by `virt-v2v-in-place`, expects `/boot/grub/grub.cfg` to be a symlink to `/boot/grub2/grub.cfg`. On affected guests GRUB2 itself is configured correctly, but this compatibility symlink is missing, so `grubby`'s file open fails. This is unrelated to [SUSE Legacy GRUB 0.97](../../../reference/known-limitations/#suse-linux-sles-sled-with-legacy-grub-097), which requires a GRUB2 upgrade instead.
|
||||
|
||||
- **Resolution**
|
||||
|
||||
Before migrating a BIOS RHEL 7 guest, confirm:
|
||||
|
||||
- `/boot/grub2/grub.cfg` exists and is non-empty (regenerate with `grub2-mkconfig -o /boot/grub2/grub.cfg` if not).
|
||||
- `/boot/grub/grub.cfg` exists as a symlink to `../grub2/grub.cfg` (`mkdir -p /boot/grub && ln -sfn ../grub2/grub.cfg /boot/grub/grub.cfg` if missing).
|
||||
- `/etc/grub2.cfg` and `/etc/grub.conf` resolve to the same file — recreate the same way if broken.
|
||||
|
||||
Then re-run the migration.
|
||||
|
||||
- **Notes**
|
||||
|
||||
- Check ahead of a migration wave: `test -L /boot/grub/grub.cfg && echo OK || echo MISSING`.
|
||||
- Observed on RHEL 7.9 (Maipo); other RHEL 7.x releases with the same layout may be affected.
|
||||
- See also: [Known Limitations](../../../reference/known-limitations/#rhel-7-guests-missing-grub-compatibility-symlink).
|
||||
|
||||
---
|
||||
|
||||
## VDDK unavailable: VMware's public download pages are down
|
||||
|
||||
- **Symptom**
|
||||
|
||||
VMware's public VDDK download pages are currently unavailable. You cannot download VDDK from
|
||||
VMware's official site.
|
||||
|
||||
- **Impact**
|
||||
|
||||
Only the **Standard copy method** requires VDDK. **vJailbreak Accelerated Copy** and
|
||||
**Storage-Accelerated Copy** do not need VDDK and are fully unaffected.
|
||||
|
||||
- **Resolution**
|
||||
|
||||
Use **vJailbreak Accelerated Copy** or **Storage-Accelerated Copy** instead of Standard copy.
|
||||
Both methods work without VDDK installed on the vJailbreak appliance.
|
||||
|
||||
:::caution[Cold migration only]
|
||||
vJailbreak Accelerated Copy supports **cold migration only**: the source VM must be powered
|
||||
off before copy begins. It does not support live (hot) migration. If live migration is required,
|
||||
wait for VDDK to become available and use Standard copy.
|
||||
:::
|
||||
|
||||
See [vJailbreak Accelerated Copy](../../../concepts/vjailbreak-accelerated-copy/) and
|
||||
[Storage-Accelerated Copy](../../../concepts/storage-accelerated-copy/) for setup instructions.
|
||||
|
||||
---
|
||||
|
||||
## Proxy VM disk attach fails when several migrations start together
|
||||
|
||||
- **Symptom**
|
||||
|
||||
A batch of [vJailbreak Accelerated Copy](../../../concepts/vjailbreak-accelerated-copy/) migrations is started at once. Some of them fail early with a vCenter error while attaching the source snapshot disks to the Proxy VM, while the rest continue into the copy phase without any problem.
|
||||
|
||||
- **Cause**
|
||||
|
||||
Each migration attaches its source disks to the Proxy VM as a vCenter VM reconfigure task. When several migrations issue these tasks against the same Proxy VM simultaneously, vCenter does not always serialize them gracefully and rejects some of the attach requests.
|
||||
|
||||
This is a **transient race condition** — the Proxy VM, its credentials, and its configuration are all fine. Only the migrations that lost the race are affected.
|
||||
|
||||
- **Resolution**
|
||||
|
||||
1. Let the surviving migrations progress past the attach step and into the copy phase.
|
||||
2. [Retry](../../how-to/retry_failed_migration/) the failed migrations. They normally succeed on the second attempt.
|
||||
|
||||
- **Notes**
|
||||
|
||||
- To reduce the chance of hitting this, stagger migration start times rather than starting a large batch at once, or register additional Proxy VMs and distribute migrations across them.
|
||||
- Use the [data copy start time](../../../concepts/migration-options/#data-copy-start-time) option to spread a wave of migrations over a window.
|
||||
- See also: [Known Limitations](../../../reference/known-limitations/#concurrent-disk-attach-can-fail).
|
||||
|
||||
---
|
||||
|
||||
## vJailbreak Accelerated Copy fails: could not identify block device
|
||||
|
||||
- **Symptom**
|
||||
|
||||
A [vJailbreak Accelerated Copy](../../../concepts/vjailbreak-accelerated-copy/) migration fails after the snapshot disk has been attached to the Proxy VM:
|
||||
|
||||
```text
|
||||
could not identify block device for disk <uuid>
|
||||
```
|
||||
|
||||
- **Cause**
|
||||
|
||||
vJailbreak locates each attached disk inside the Proxy VM by matching its disk UUID to a block device. Two conditions must be met for this to work:
|
||||
|
||||
1. `disk.EnableUUID` is set to `TRUE` on the Proxy VM, so the UUID is visible to the guest.
|
||||
2. The Proxy VM's first SCSI controller (**SCSI controller 0**) is of type **VMware Paravirtual (PVSCSI)**. Only PVSCSI is supported — LSI Logic SAS, LSI Logic Parallel, and BusLogic Parallel controllers do not work.
|
||||
|
||||
- **Resolution**
|
||||
|
||||
1. Confirm `disk.EnableUUID = TRUE` on the Proxy VM: vSphere Client → **Edit Settings** → **VM Options** → **Advanced** → **Edit Configuration**.
|
||||
2. Confirm **SCSI controller 0** is **VMware Paravirtual**. If it is not, power off the Proxy VM, then in **Edit Settings** → **Virtual Hardware** set **SCSI controller 0** → **Change Type** → **VMware Paravirtual**, and power it back on.
|
||||
3. Re-verify the Proxy VM in the vJailbreak UI and re-run the migration.
|
||||
|
||||
- **Notes**
|
||||
|
||||
- SSH into the Proxy VM and run `lsblk` to confirm the attached disks are visible to the guest.
|
||||
- Check vCenter events on the Proxy VM for disk attach errors if the disk never appears.
|
||||
- See also: [Known Limitations](../../../reference/known-limitations/#proxy-vm-must-use-a-pvscsi-controller) and [Configure the SCSI Controller Type on the Proxy VM](../../../concepts/vjailbreak-accelerated-copy/#configure-the-scsi-controller-type-on-the-proxy-vm).
|
||||
@@ -0,0 +1,105 @@
|
||||
---
|
||||
title: VMware Residual Artifacts
|
||||
description: Residual VMware artifacts
|
||||
---
|
||||
|
||||
In v0.4.4, the following artifacts remain on the Windows VMs after selecting "Remove VMware Tools" option:
|
||||
|
||||
|
||||
### 1. VMware Driver Files
|
||||
|
||||
| Driver File Path | 2012 | 2016 | 2019 | 2022 | 2025 | Win11 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| C:\Windows\System32\drivers\vmci.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vm3dmp.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vmaudio.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vmhgfs.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vmmemctl.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vmmouse.sys | Not Found | Not Found | Not Found | Not Found | Not Found | **Present** |
|
||||
| C:\Windows\System32\drivers\vmrawdsk.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vmtools.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vmusbmouse.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vmvss.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vsock.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vmx_svga.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vmxnet3.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vm3dmp-stats.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vm3dmp_loader.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vm3dmp-debug.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vm3dservice.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vmgid.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vmgencounter.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vms3cap.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Windows\System32\drivers\vmstorfl.sys | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
|
||||
### 2. VMware Registry Keys
|
||||
|
||||
| Registry Key Path | 2012 | 2016 | 2019 | 2022 | 2025 | Win11 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| HKLM:\SOFTWARE\VMware, Inc. | **Present** | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SOFTWARE\VMware | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SOFTWARE\WOW6432Node\VMware, Inc. | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SOFTWARE\WOW6432Node\VMware | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\vmci | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\vm3dmp | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\vm3dmp_loader | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\vm3dmp-debug | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\vm3dmp-stats | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\vm3dservice | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\vmaudio | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\vmhgfs | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\VMMemCtl | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\vmmouse | Not Found | Not Found | Not Found | Not Found | Not Found | **Present** |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\vmrawdsk | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\VMRawDisk | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\VMTools | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\vmusbmouse | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\vmvss | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\vmvsock | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\VMwareCAF | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\VMwareCAFCommAmqpListener | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\VMwareCAFManagementAgentHost | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| HKLM:\SYSTEM\CurrentControlSet\Services\vnetWFP | **Present** | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
|
||||
### 3. VMware Folders
|
||||
|
||||
| Folder Path | 2012 | 2016 | 2019 | 2022 | 2025 | Win11 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| C:\Program Files\VMware | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Program Files (x86)\VMware | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Program Files\Common Files\VMware | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Program Files (x86)\Common Files\VMware | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\ProgramData\VMware | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Users\Administrator\AppData\Local\VMware | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\Users\Administrator\AppData\Roaming\VMware | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
| C:\ProgramData\Microsoft\Windows\Start Menu\Programs\VMware | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
|
||||
### 4. Startup Entries
|
||||
|
||||
| Startup Entry | 2012 | 2016 | 2019 | 2022 | 2025 | Win11 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| vmtoolsd (HKLM:\Software\Microsoft\Windows\CurrentVersion\Run) | Not Found | Not Found | Not Found | Not Found | Not Found | Not Found |
|
||||
|
||||
### 5. VMware Devices (Device Manager)
|
||||
|
||||
Devices with **Error** status indicate a residual device entry whose driver was removed with VMware Tools.
|
||||
|
||||
| Device Name | 2012 | 2016 | 2019 | 2022 | 2025 | Win11 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| VMware VMCI Host Device | Error | Error | Error | Not Found | Not Found | Not Found |
|
||||
| VMware Pointing Device | Error | Error | Error | Not Found | Not Found | Error |
|
||||
| **Total devices found** | **2** | **2** | **2** | **0** | **0** | **1** |
|
||||
|
||||
### 6. Impact of Remaining Artifacts
|
||||
|
||||
| Artifact | Versions | Impact |
|
||||
|---|---|---|
|
||||
| `vmmouse.sys` + `HKLM:\SYSTEM\CurrentControlSet\Services\vmmouse` | Win11 | Residual VMware mouse driver. After migration of VMware hypervisor, there's no VMware hardware to drive, so it's inert. The Pointing Device shows Error in Device Manager but Windows falls back to standard HID drivers — mouse input works normally. |
|
||||
| `HKLM:\SOFTWARE\VMware, Inc.` | 2012 | Metadata-only registry key left by the VMware installer. No services load from it, no runtime effect. May appear in software inventory/audit tools as VMware still "installed" but it's not. |
|
||||
| `HKLM:\SYSTEM\CurrentControlSet\Services\vnetWFP` | 2012 | VMware virtual network Windows Filtering Platform driver. The service entry remains but since the driver binary is gone, Windows will fail to start it silently. No network degradation observed. |
|
||||
| VMware Pointing Device / VMCI Host Device (Error) | 2012, 2016, 2019, Win11 | Phantom device entries in Device Manager with no loaded driver (Code 28). Cosmetic only — no runtime effect, no performance impact, no BSOD risk. Windows ignores driver-less device entries during normal operation. |
|
||||
|
||||
**Summary:**
|
||||
- None of these remnants are harmful to VM operation or stability post-migration.
|
||||
- The `vnetWFP` service key on Windows 2012 is the most noteworthy from a compliance audit standpoint, but has no observed runtime impact.
|
||||
- The Error devices in Device Manager are cosmetic — they do not affect functionality.
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: Windows Dynamic Disk (LDM) migration issue
|
||||
description: Windows VMs with a dynamic disk (LDM) system volume are supported through a dedicated migration path.
|
||||
sidebar:
|
||||
hidden: true
|
||||
---
|
||||
|
||||
:::note[This page has moved]
|
||||
Windows VMs with an LDM system volume are supported. Everything about this
|
||||
migration path — prerequisites, what vJailbreak does, the cutover, and
|
||||
troubleshooting — is documented in one place:
|
||||
[Windows Dynamic Disk (LDM) Migration](../../how-to/windows-ldm-migration/).
|
||||
:::
|
||||
|
||||
## Why LDM needs a different path
|
||||
|
||||
**LDM (Logical Disk Manager)** is Windows' volume manager for "dynamic disks". It
|
||||
is conceptually similar to Linux LVM, but it stores its volume metadata in a
|
||||
private database at the end of each disk rather than in a standard partition
|
||||
table.
|
||||
|
||||
`virt-v2v` converts a guest by inspecting it with libguestfs, reading the
|
||||
`SYSTEM` and `SOFTWARE` registry hives with Hivex, and writing VirtIO drivers and
|
||||
registry changes back into the offline filesystem. When the Windows system volume
|
||||
is an LDM volume, libguestfs cannot reliably assemble it, so inspection fails
|
||||
before conversion can start.
|
||||
|
||||
Rather than requiring the disk to be converted to basic beforehand, vJailbreak
|
||||
skips conversion for these guests and brings the VM up on an emulated SATA
|
||||
controller, which Windows can boot without VirtIO drivers. A temporary virtio
|
||||
temporary disk lets Windows install the `viostor` driver itself, and the migration
|
||||
then waits at the **LDM Boot Verification** phase for you to move the root disk to
|
||||
virtio.
|
||||
|
||||
:::caution
|
||||
Only the **system volume** matters. If just the data disks are dynamic, the VM
|
||||
migrates normally and no special handling is needed.
|
||||
:::
|
||||
|
||||
## Converting to basic disks is no longer required
|
||||
|
||||
Earlier versions of this guide recommended running `diskpart` → `convert basic` on
|
||||
the source VM before migrating. That is no longer necessary, and `convert basic`
|
||||
requires an empty disk in any case. Follow the
|
||||
[LDM migration guide](../../how-to/windows-ldm-migration/) instead.
|
||||
@@ -0,0 +1,169 @@
|
||||
---
|
||||
title: Windows Offline Disks After Migration
|
||||
description: Troubleshooting guide for Windows VMs with offline disks after migration from VMware to PCD
|
||||
---
|
||||
|
||||
# Windows Offline Disks After Migration
|
||||
|
||||
## Problem Description
|
||||
|
||||
After migrating a Windows VM from VMware vCenter to PCD using vJailbreak, additional disks (beyond the primary C: drive) may not be visible inside the Windows operating system, even though they are successfully attached to the VM in PCD.
|
||||
|
||||
### Symptoms
|
||||
|
||||
- The VM migrates successfully and shows as active in PCD
|
||||
- PCD shows all volumes/disks are attached (e.g., 3 disks attached)
|
||||
- Inside the Windows VM, only the primary C: drive is visible
|
||||
- Additional drives (e.g., E:, F:, G:) that existed before migration are missing
|
||||
- The disks exist but are in an "Offline" state in Windows Disk Management
|
||||
|
||||
### Root Cause
|
||||
|
||||
This issue occurs due to Windows SAN Policy settings. When Windows detects disks on a SAN (Storage Area Network), it applies a policy that determines whether new disks are automatically brought online or kept offline.
|
||||
|
||||
After migration from VMware to PCD, the storage subsystem changes, and Windows may apply the **"Offline Shared"** SAN policy to the migrated disks. This policy keeps disks offline by default to prevent data corruption in shared storage scenarios.
|
||||
|
||||
The default SAN policies in Windows are:
|
||||
- **Offline Shared**: Keeps all shared disks offline (common after migration)
|
||||
- **Offline All**: Keeps all new disks offline
|
||||
- **Online All**: Automatically brings all new disks online
|
||||
|
||||
## Manual Workaround
|
||||
|
||||
Before migrating the VM, you can manually fix this issue by changing the SAN policy and bringing disks online.
|
||||
|
||||
### Step 1: Check Current SAN Policy
|
||||
|
||||
Open Command Prompt as Administrator and run:
|
||||
|
||||
```cmd
|
||||
C:\> diskpart
|
||||
DISKPART> SAN
|
||||
```
|
||||
|
||||
You will likely see:
|
||||
```
|
||||
SAN Policy : Offline Shared
|
||||
```
|
||||
|
||||
### Step 2: Change SAN Policy to Online All
|
||||
|
||||
```cmd
|
||||
DISKPART> SAN POLICY=OnlineAll
|
||||
```
|
||||
|
||||
### Step 3: Verify the Change
|
||||
|
||||
```cmd
|
||||
DISKPART> SAN
|
||||
```
|
||||
|
||||
You should now see:
|
||||
```
|
||||
SAN Policy : Online All
|
||||
```
|
||||
|
||||
### Step 4: Bring Offline Disks Online
|
||||
|
||||
While still in diskpart:
|
||||
|
||||
```cmd
|
||||
DISKPART> list disk
|
||||
```
|
||||
|
||||
Identify offline disks (marked with an asterisk *), then for each offline disk:
|
||||
|
||||
```cmd
|
||||
DISKPART> select disk <number>
|
||||
DISKPART> online disk
|
||||
```
|
||||
|
||||
### Step 5: Exit and Verify
|
||||
|
||||
```cmd
|
||||
DISKPART> exit
|
||||
```
|
||||
|
||||
Check File Explorer - your drives (E:, F:, G:, etc.) should now be visible.
|
||||
|
||||
## Automated Solution
|
||||
|
||||
vJailbreak provides automated scripts to detect and fix this issue during first boot after migration.
|
||||
|
||||
### Available Scripts
|
||||
|
||||
Two BAT scripts are available in the `scripts/firstboot/windows/` directory. These scripts generate PowerShell scripts that run on first boot:
|
||||
|
||||
1. **`check-disks.bat`** - Generates a diagnostic PowerShell script that only checks disk status
|
||||
2. **`disk-online-fix.bat`** - Generates an automated fix PowerShell script that brings offline disks online
|
||||
|
||||
**Usage**: Copy the contents of either BAT file and paste it into the **Post Migration Script** field in the migration form. The script will execute automatically on first boot after migration.
|
||||
|
||||
### Script 1: Check Disks (Diagnostic Only)
|
||||
|
||||
The `check-disks.bat` script generates `check-disks.ps1` which performs a read-only analysis:
|
||||
|
||||
- Scans all physical disks
|
||||
- Reports operational status (Online/Offline)
|
||||
- Lists partitions and drive letter assignments
|
||||
- Identifies disks without drive letters
|
||||
- Checks for read-only disks and health issues
|
||||
- Generates a detailed report at `C:\DiskStatus_Report.txt`
|
||||
|
||||
|
||||
### Script 2: Disk Online Fix (Automated Repair)
|
||||
|
||||
The `disk-online-fix.bat` script generates and executes `check-disks-fix.ps1` which automatically fixes offline disk issues:
|
||||
|
||||
- Performs all diagnostic checks from Script 1
|
||||
- **Automatically brings ALL offline disks online**
|
||||
- Logs all actions to `C:\DiskStatus_Report.txt`
|
||||
|
||||
**Note**: The generated PowerShell script (`check-disks-fix.ps1`) is a separate file from the diagnostic-only `check-disks.ps1`. It includes all diagnostic functionality plus automated repair capabilities.
|
||||
|
||||
|
||||
## ⚠️ Important Warnings
|
||||
|
||||
### Blanket Online Policy
|
||||
|
||||
The automated fix script uses a **blanket approach** to bring ALL offline disks online without discrimination. This is necessary because:
|
||||
|
||||
- Pre-migration disk states (online/offline) are unknown
|
||||
- The script cannot determine if a disk was intentionally kept offline before migration
|
||||
- This is designed for automated firstboot scenarios after VM conversion
|
||||
|
||||
### Risks and Considerations
|
||||
|
||||
1. **Intentionally Offline Disks**: If the source VM had disks that were intentionally kept offline (for backup, security, or operational reasons), the script will bring them online. This may not align with your original configuration.
|
||||
|
||||
2. **Shared Storage**: In environments with shared storage, bringing disks online indiscriminately could potentially cause issues if the same disk is accessed by multiple systems.
|
||||
|
||||
3. **Testing Required**: Always test this script in a non-production environment first to ensure it aligns with your migration policy.
|
||||
|
||||
4. **No Drive Letter Assignment**: The script does NOT automatically assign drive letters to partitions. If a partition lacks a drive letter, you must assign it manually using Disk Management or PowerShell cmdlets.
|
||||
|
||||
### Recommendations
|
||||
|
||||
- Review the diagnostic output from `check-disks.bat` before running the automated fix
|
||||
- Document which disks should be online in your source environment
|
||||
- Test the migration process with a non-critical VM first
|
||||
- Review the log file at `C:\DiskStatus_Report.txt` after running the fix script
|
||||
- Manually verify that all expected drives are accessible after the fix
|
||||
|
||||
## Prevention
|
||||
|
||||
To prevent this issue in future migrations, you can:
|
||||
|
||||
1. **Pre-configure SAN Policy**: Before migration, set the SAN policy on the source VM to `OnlineAll`
|
||||
2. **Post-migration Automation**: Copy the contents of `disk-online-fix.bat` into the Post Migration Script field in the migration form
|
||||
3. **Document Disk States**: Maintain documentation of which disks should be online/offline for each VM
|
||||
|
||||
:::caution[LDM system volumes]
|
||||
The automated solution above relies on firstboot scripts, which `virt-v2v` installs
|
||||
during conversion. Windows VMs whose system volume is on a dynamic disk (LDM) skip
|
||||
conversion, so the Post Migration Script does not run for them — the SAN policy
|
||||
**must** be set on the source VM beforehand. Leaving a disk offline on these guests
|
||||
breaks the LDM volume set. See
|
||||
[Windows Dynamic Disk (LDM) Migration](../../how-to/windows-ldm-migration/).
|
||||
:::
|
||||
|
||||
@@ -0,0 +1,191 @@
|
||||
---
|
||||
title: vJailbreak
|
||||
description: A free and open-source tool that simplifies the migration of virtual machines from VMware to any OpenStack-compliant cloud.
|
||||
template: splash
|
||||
head:
|
||||
- tag: script
|
||||
content: |
|
||||
window.location.href = 'https://platform9.com/vjailbreak/';
|
||||
hero:
|
||||
tagline: Effortless Open-Source VMware to OpenStack Migration
|
||||
image:
|
||||
html: |
|
||||
<div class="video-container">
|
||||
<div class="video-wrapper">
|
||||
<iframe
|
||||
src="https://www.youtube.com/embed/FgkBWttOfsc"
|
||||
title="vJailbreak Demo"
|
||||
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
|
||||
allowfullscreen
|
||||
></iframe>
|
||||
</div>
|
||||
</div>
|
||||
actions:
|
||||
- text: Getting Started
|
||||
link: introduction/getting_started/
|
||||
icon: right-arrow
|
||||
- text: Clone the Repo
|
||||
link: https://github.com/platform9/vjailbreak
|
||||
icon: github
|
||||
variant: minimal
|
||||
align: center
|
||||
---
|
||||
|
||||
import {
|
||||
Card,
|
||||
CardGrid,
|
||||
Icon,
|
||||
Steps,
|
||||
Tabs,
|
||||
TabItem,
|
||||
} from "@astrojs/starlight/components"
|
||||
import AboutVJB from "../../components/about.astro"
|
||||
import Aurora from "../../components/Aurora.astro"
|
||||
|
||||
<Aurora bands={100} />
|
||||
|
||||
### Download the latest Version
|
||||
|
||||
<Steps>
|
||||
<ol>
|
||||
<li>
|
||||
**Install ORAS**
|
||||
|
||||
<Tabs syncKey="oras">
|
||||
<TabItem label="brew">
|
||||
```
|
||||
brew install oras
|
||||
```
|
||||
</TabItem>
|
||||
|
||||
<TabItem label="snap">
|
||||
```
|
||||
snap install oras --classic
|
||||
```
|
||||
</TabItem>
|
||||
|
||||
<TabItem label="Apple Silicon">
|
||||
```
|
||||
VERSION="1.2.2"
|
||||
curl -LO "https://github.com/oras-project/oras/releases/download/v${VERSION}/oras_${VERSION}_darwin_arm64.tar.gz"
|
||||
mkdir -p oras-install/
|
||||
tar -zxf oras_${VERSION}_*.tar.gz -C oras-install/
|
||||
sudo mv oras-install/oras /usr/local/bin/
|
||||
rm -rf oras_${VERSION}_*.tar.gz oras-install/
|
||||
```
|
||||
</TabItem>
|
||||
|
||||
<TabItem label="Linux">
|
||||
```
|
||||
VERSION="1.2.2"
|
||||
curl -LO "https://github.com/oras-project/oras/releases/download/v${VERSION}/oras_${VERSION}_linux_amd64.tar.gz"
|
||||
mkdir -p oras-install/
|
||||
tar -zxf oras_${VERSION}_*.tar.gz -C oras-install/
|
||||
sudo mv oras-install/oras /usr/local/bin/
|
||||
rm -rf oras_${VERSION}_*.tar.gz oras-install/
|
||||
```
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
**Download Image**
|
||||
|
||||
```
|
||||
oras pull quay.io/platform9/vjailbreak:v0.4.10
|
||||
```
|
||||
</li>
|
||||
|
||||
<li>
|
||||
**Get PCD**
|
||||
|
||||
<Tabs syncKey="pcd" variant="underlined">
|
||||
<TabItem label="PCD">
|
||||
```
|
||||
https://platform9.com/private-cloud-director/
|
||||
```
|
||||
</TabItem>
|
||||
|
||||
<TabItem label="PCD Community Edition (Free)">
|
||||
```
|
||||
https://platform9.com/docs/private-cloud-director/private-cloud-director/getting-started-with-community-edition
|
||||
```
|
||||
</TabItem>
|
||||
|
||||
<TabItem label="OpenStack">
|
||||
```
|
||||
https://www.openstack.org/
|
||||
```
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
</li>
|
||||
|
||||
</ol>
|
||||
</Steps>
|
||||
|
||||
<div style="text-align: center; width: 100%; padding: 2rem 1rem;">
|
||||
<h2
|
||||
class="gradient-heading"
|
||||
style="font-size: 2.4rem; margin-bottom: 1.5rem;"
|
||||
>
|
||||
Enterprise VM Migration: VMware to OpenStack, Simplified
|
||||
</h2>
|
||||
<p style="font-size: 1.2rem; line-height: 1.6; color: var(--sl-color-gray-2); max-width: 1200px; margin: 0 auto;">
|
||||
vJailbreak is an open-source tool featuring a user-friendly interface
|
||||
designed to simplify and accelerate the migration of virtual machines (VMs)
|
||||
from VMware vSphere environments to any OpenStack-compliant cloud. It
|
||||
eliminates the complexities of cross-platform VM migration, enabling you to
|
||||
modernize your infrastructure with minimal disruption and a streamlined,
|
||||
visual workflow.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<h2 class="section-title">Key Benefits</h2>
|
||||
|
||||
<CardGrid stagger>
|
||||
<Card title="Visual Interface" icon="laptop">
|
||||
Intuitive UI with no command-line requirements for seamless VM migration
|
||||
</Card>
|
||||
|
||||
<Card title="Fast & Efficient" icon="rocket">
|
||||
Automated tasks with real-time progress tracking reduce migration time
|
||||
</Card>
|
||||
|
||||
<Card title="Zero Disruption" icon="warning">
|
||||
Maintain source environment operations with minimal downtime
|
||||
</Card>
|
||||
|
||||
<Card title="Cost Effective" icon="seti:todo">
|
||||
Open-source solution eliminating expensive licensing costs
|
||||
</Card>
|
||||
|
||||
<Card title="OpenStack Ready" icon="puzzle">
|
||||
Compatible with any standard OpenStack-compliant cloud platform
|
||||
</Card>
|
||||
|
||||
<Card title="Step-by-Step Guide" icon="list-format">
|
||||
Guided workflow with automated health checks and validation
|
||||
</Card>
|
||||
</CardGrid>
|
||||
|
||||
<h2 class="section-title">Get Started</h2>
|
||||
|
||||
<p style="text-align: center; color: var(--sl-color-gray-2); font-size: 1.2rem; margin-bottom: 2rem;">
|
||||
Ready to experience simplified, UI-driven VM migration?
|
||||
</p>
|
||||
|
||||
<CardGrid stagger>
|
||||
<Card title="Deploy vJailbreak" icon="rocket">
|
||||
Deploy vJailbreak and connect it to your vSphere and OpenStack environments.
|
||||
Learn more about installation, configuration, and usage in the [vJailbreak
|
||||
Documentation](introduction/getting_started/).
|
||||
</Card>
|
||||
<Card title="Contribute to vJailbreak" icon="add-document">
|
||||
Help improve vJailbreak by contributing code, documentation, or bug reports.
|
||||
View our [contribution
|
||||
guidelines](https://github.com/platform9/vjailbreak/blob/main/CONTRIBUTING.md)
|
||||
to get started.
|
||||
</Card>
|
||||
</CardGrid>
|
||||
|
||||
<AboutVJB></AboutVJB>
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: Components
|
||||
description: Overview of vJailbreak components
|
||||
---
|
||||
|
||||
|
||||
# Architecture
|
||||
Below is high level architecture of how vJailbreak works. vJailbreak runs
|
||||
in a virtual machine in the target OpenStack environment. vJailbreak connects with VMware environment via vSphere APIs, using the VDDK library for the Standard copy method only. vJailbreak Accelerated Copy and Storage-Accelerated Copy transfer disk data without requiring VDDK. It also uses the OpenStack SDK to interact with the OpenStack environment and perform the necessary provisioning operations including creation of volumes, VMs.
|
||||
|
||||
|
||||
|
||||
# Components
|
||||
Below is an overview of each component and its role in the migration process.
|
||||
|
||||
### v2v-helper
|
||||
The `v2v-helper` is the main application responsible for executing the migration process. It is designed to run as a pod within the vJailbreak virtual machine (VM) in the target OpenStack environment. It supports three storage copy methods: Standard (VDDK-based), vJailbreak Accelerated Copy (Hot-Add, VDDK-free), and Storage-Accelerated Copy (XCOPY, VDDK-free). Only Standard copy requires VDDK.
|
||||
|
||||
### UI
|
||||
The `UI` component provides a user-friendly interface for vJailbreak. It allows users to manage and monitor the migration process through an intuitive graphical interface.
|
||||
|
||||
### migration-controller
|
||||
The `migration-controller` is a Kubernetes controller that schedules and manages the migration tasks. It ensures that migrations are executed efficiently and in accordance with the defined policies.
|
||||
|
||||
### v2v-cli
|
||||
The `v2v-cli` is a command-line interface tool that can initiate the migration process. While it is available, it is not required in the current version of vJailbreak, as the primary interface is the UI.
|
||||
|
||||
By understanding these components, users can better appreciate the architecture and functionality of vJailbreak, enabling them to effectively manage and execute VM migrations.
|
||||
@@ -0,0 +1,129 @@
|
||||
---
|
||||
title: FAQ
|
||||
description: frequently asked questions
|
||||
---
|
||||
|
||||
### What should I do if I cannot download VDDK?
|
||||
|
||||
VMware's public VDDK download pages are currently unavailable. VDDK is only required for the
|
||||
**Standard** storage copy method.
|
||||
|
||||
**vJailbreak Accelerated Copy** and **Storage-Accelerated Copy** do not require VDDK and can be
|
||||
used immediately:
|
||||
|
||||
- [vJailbreak Accelerated Copy](../../concepts/vjailbreak-accelerated-copy/): works with any
|
||||
datastore; **cold migration only** (source VM must be powered off before copy begins, live/hot
|
||||
migration is not supported)
|
||||
- [Storage-Accelerated Copy](../../concepts/storage-accelerated-copy/): requires a supported
|
||||
storage array (Pure Storage or NetApp); cold migration only
|
||||
|
||||
### Are IPs and MAC addresses persisted?
|
||||
Yes, if your OpenStack network has a valid subnet range that allows the IP to be allocated, vJailbreak will create a port with the same MAC address and IP address as the source VM.
|
||||
|
||||
### Are network interface names persisted?
|
||||
Yes, vJailbreak can preserve network interface names during migration.
|
||||
|
||||
To enable this behavior, select **Persist source network interfaces** in the migration form under **Migration Options**.
|
||||
|
||||
Read more in [Migration Options](../../concepts/migration-options/#persist-source-network-interfaces).
|
||||
|
||||
### What OS versions are supported?
|
||||
We internally use virt-v2v, so all operating systems supported for conversion by virt-v2v are supported by vJailbreak. You can find a detailed list of them [here](https://libguestfs.org/virt-v2v-support.1.html#guests).
|
||||
|
||||
### Do I need to perform any manual steps to remove VMware Tools?
|
||||
No, vJailbreak will remove them for you, with the help of virt-v2v. The process that virt-v2v uses along with alternative approaches can be found [here](https://libguestfs.org/virt-v2v.1.html#converting-a-windows-guest).
|
||||
|
||||
### Do I need to perform any manual steps to install drivers for Linux and Windows VMs?
|
||||
No, vJailbreak will install it for you. For Windows, we allow you to specify a URL for a specific version of virtio drivers. This is useful for older Windows versions, eg. Windows Server 2012, which specifically need [v0.1.189](https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.189-1/virtio-win-0.1.189.iso) in order to work.
|
||||
|
||||
### Why does the conversion step take time?
|
||||
The delay is typically not because a single script is slow. The overall conversion process includes OS-level changes that take time, such as installing VirtIO drivers, removing old hypervisor drivers, and (for Windows guests) performing registry changes.
|
||||
|
||||
The helper scripts that apply static changes (for example, writing mount persistence entries to `/etc/fstab`) are simple and usually complete quickly.
|
||||
|
||||
Conversion time depends heavily on your infrastructure performance (especially CPU) and VM-specific factors, including the guest OS and root disk size.
|
||||
|
||||
### Why does nbdcopy fail during disk copy?
|
||||
If this issue is seen, most of the time it is a DNS/name-resolution problem. Debug logs typically show DNS resolution errors when vJailbreak tries to connect to an ESXi host.
|
||||
|
||||
Error signature:
|
||||
```text
|
||||
failed to run nbdcopy: exec: already started
|
||||
```
|
||||
|
||||
See: [Debug Logs](../../guides/troubleshooting/debuglogs/).
|
||||
|
||||
See the troubleshooting guide: [nbdcopy fails during disk copy (often DNS resolution)](../../guides/troubleshooting/nbdcopy-fails-after-vm-moved-esxi-host/).
|
||||
|
||||
### What do when virt-v2v fails with `rename: /sysroot/etc/resolv.conf ... Operation not permitted`?
|
||||
|
||||
The conversion fails because `/etc/resolv.conf` is marked **immutable** inside the source VM. `virt-v2v` cannot rename or replace immutable files during guest filesystem conversion.
|
||||
|
||||
**Quick fix**: Inside the source VM, remove the immutable attribute before migrating:
|
||||
|
||||
```bash
|
||||
chattr -i /etc/resolv.conf
|
||||
```
|
||||
|
||||
For the full symptom description, root cause analysis, and verification steps, see: [virt-v2v fails: rename /sysroot/etc/resolv.conf Operation not permitted](../../guides/troubleshooting/troubleshooting/#virt-v2v-fails-rename-sysrootetcresolvconf-operation-not-permitted)
|
||||
|
||||
### How does Vjailbreak handle flavors of the vm in the target openstack environment?
|
||||
|
||||
vJailbreak provides users the flexibility to assign desired OpenStack flavors to virtual machines during the migration setup. If the user specifies a flavor in the migration form, vJailbreak will honor that choice during provisioning on the target OpenStack environment. When migrating via CLI/kubectl, the same explicit choice can be made by setting `spec.targetFlavorId` on the VM's `VMwareMachine` custom resource — see [Explicitly select the target OpenStack flavor](../../guides/CLI-API/migrating_using_cli_and_kubectl/#optional-explicitly-select-the-target-openstack-flavor).
|
||||
|
||||
If no flavor is explicitly chosen, vJailbreak automatically selects the most appropriate flavor based on the VM's resource requirements (We always try to find the exact match if not the next best match). In cases where no suitable flavor is found, the UI will display a warning. If the user proceeds despite the warning, the migration will fail with a clear error message indicating that a compatible flavor could not be found.
|
||||
|
||||
#### Hotplug Flavor Support
|
||||
|
||||
vJailbreak supports migrating VMs to OpenStack flavors that have **hotplug** CPU and RAM enabled. Hotplug allows live resize of vCPUs and memory without powering off the VM after migration.
|
||||
|
||||
To use hotplug after migration:
|
||||
|
||||
1. **On Platform9 Private Cloud Director (PCD)**: a hotplug base flavor named `hotplug` is available by default. While triggering the migration, simply select the `hotplug` flavor for the VMs that should support live resize.
|
||||
|
||||
2. **On other OpenStack environments**: ask your administrator to create or identify a flavor with hotplug-enabled extra specs, and select it in the migration form. Example:
|
||||
|
||||
```bash
|
||||
openstack flavor set <flavor-name> \
|
||||
--property hw:cpu_policy=mixed \
|
||||
--property hw:cpu_max_vcpus=<max-vcpus>
|
||||
```
|
||||
|
||||
3. After migration completes, resize the VM to add or remove vCPUs and RAM without a reboot.
|
||||
|
||||
When a hotplug base flavor (0 vCPU, 0 RAM — such as PCD's default `hotplug` flavor) is assigned, vJailbreak sets the VM's hotplug metadata at creation time: the current values (`HOTPLUG_CPU`, `HOTPLUG_MEMORY`) match the source VM, and the maximum values (`HOTPLUG_CPU_MAX`, `HOTPLUG_MEMORY_MAX`) are set to **twice** the source VM's vCPU and memory. This gives every migrated VM room to live-resize up to 2x its original size. Hotplug metadata cannot be changed after the VM is created.
|
||||
|
||||
:::note
|
||||
Standard flavors without hotplug extra specs require a VM power-off for resize. See [Known Limitations: Hotplug Flavor Requirements](../../reference/known-limitations/#hotplug-flavor-requirements) for details on flavor prerequisites and the metadata reference.
|
||||
:::
|
||||
|
||||
### Can vJailbreak migrate VMs running Docker Engine?
|
||||
Yes, vJailbreak can migrate VMs running Docker Engine without any issues. vJailbreak performs VM-level migration and is agnostic to the workloads running inside the VM. Docker Engine is simply software running on the guest operating system, and the migration process handles it like any other application.
|
||||
|
||||
### Can vJailbreak migrate VMs that are part of a Kubernetes cluster?
|
||||
Yes, you can migrate VMs that are part of a Kubernetes cluster. However, it's important to understand that vJailbreak operates purely as a VM migration tool and has no awareness of Kubernetes components or distributed applications running on the VM.
|
||||
|
||||
Users are responsible for taking necessary steps to ensure no disruption to applications and the distributed architecture of Kubernetes. This may include draining nodes, managing pod scheduling, and coordinating the migration with cluster operations. vJailbreak is not responsible for managing any workload-specific concerns.
|
||||
|
||||
### Can vJailbreak migrate Kubernetes Persistent Volume Claims (PVCs)?
|
||||
No, vJailbreak does not migrate PVCs. PVCs are Kubernetes constructs managed by CSI drivers and storage backends. vJailbreak has no visibility into these workload-level abstractions.
|
||||
|
||||
vJailbreak migrates virtual machines along with the disks that are **currently attached** to those VMs at the time of migration. Any storage managed by Kubernetes (such as PVCs) must be handled separately using Kubernetes-native tools or storage migration solutions.
|
||||
|
||||
### Can vJailbreak migrate VMs running Docker Swarm clusters?
|
||||
Yes, vJailbreak can migrate VMs that are part of a Docker Swarm cluster. However, the same principles apply as with any distributed workload: vJailbreak performs VM-level migration and does not manage workload-specific concerns.
|
||||
|
||||
Users must take appropriate precautions for Docker Swarm, such as draining nodes, managing service placement, and ensuring cluster quorum is maintained during migration. vJailbreak does not inspect or manage what is running inside the VM.
|
||||
|
||||
|
||||
### How do I migrate a Windows VM with Group Policy (GPO) applied?
|
||||
|
||||
GPO settings can block driver injection and registry changes that vJailbreak performs during conversion. The migration may succeed but produce a VM that fails to boot or has missing drivers.
|
||||
|
||||
See the [GPO Migration Guide](../../guides/how-to/gpo_migration/) for steps to temporarily disable or scope down GPO before migration.
|
||||
|
||||
### How do I migrate a VM with vTPM (Virtual Trusted Platform Module) enabled?
|
||||
|
||||
VMs with vTPM and Virtualization Based Security (VBS) enabled require special handling. You must temporarily disable vTPM on the source VM before migration, then re-enable it on the destination VM post-migration.
|
||||
|
||||
See the [vTPM Migration Guide](../../guides/how-to/vtpm_migration/) for step-by-step instructions.
|
||||
@@ -0,0 +1,323 @@
|
||||
---
|
||||
title: Getting Started
|
||||
description: Usage
|
||||
---
|
||||
|
||||
vJailbreak works by running itself as a VM on the target OpenStack cloud. It connects remotely
|
||||
to the VMware vSphere environment to perform the migration. vJailbreak supports multiple storage
|
||||
copy methods: the **Standard** copy method uses the VMware VDDK library, while **vJailbreak
|
||||
Accelerated Copy** and **Storage-Accelerated Copy** do not require VDDK. These are
|
||||
the recommended methods when VDDK is unavailable.
|
||||
|
||||
It also uses the OpenStack SDK to interact with the OpenStack environment and perform the necessary
|
||||
provisioning operations including creation of volumes, VMs.
|
||||
|
||||
### Network and access requirements
|
||||
Ensure that your vJailbreak VM can communicate with your OpenStack and VMware environments. This includes any setup required for VPNs, etc.
|
||||
|
||||
:::note[vJailbreak Accelerated Copy]
|
||||
When using the **vJailbreak Accelerated Copy** data copy method, the onboarded Proxy VM must accept the following inbound TCP traffic from the vJailbreak VM:
|
||||
- **10809–11808** — used by `qemu-nbd` to expose attached disks (one port per disk copied in parallel)
|
||||
- **22** — SSH, used by vJailbreak to control the Proxy VM
|
||||
:::
|
||||
|
||||
<ReadMore>Further details can be found in [Prerequisites](../prerequisites/).</ReadMore>
|
||||
|
||||
### Download vJailbreak Image
|
||||
|
||||
You can download the vJailbreak image using one of the following methods:
|
||||
|
||||
#### Option 1: Using ORAS
|
||||
|
||||
Download and install [ORAS](https://oras.land/docs/installation), a toolkit to download the qcow2 image of vJailbreak. Then, download the latest version of the vJailbreak image with the following command:
|
||||
```shell
|
||||
oras pull quay.io/platform9/vjailbreak:v0.4.10
|
||||
```
|
||||
|
||||
For older versions, download the vJailbreak image with the following command:
|
||||
```shell
|
||||
oras pull quay.io/platform9/vjailbreak:<version>
|
||||
```
|
||||
|
||||
These will download the vJailbreak qcow2 folder containing the image locally in the current directory named `vjailbreak_qcow2/vjailbreak-image.qcow2`.
|
||||
|
||||
#### Option 2: Direct Download from S3
|
||||
|
||||
For the latest version, download directly using wget:
|
||||
```shell
|
||||
wget https://vjailbreak.s3.us-west-2.amazonaws.com/releases/latest/vjailbreak.qcow2
|
||||
```
|
||||
|
||||
For older versions, download directly using wget:
|
||||
```shell
|
||||
wget https://vjailbreak.s3.us-west-2.amazonaws.com/releases/<version>/vjailbreak.qcow2
|
||||
```
|
||||
|
||||
These will download the vJailbreak qcow2 image locally in the same directory named `vjailbreak.qcow2`.
|
||||
|
||||
Note: This direct download method is supported starting from v0.3.2 and later versions.
|
||||
|
||||
### Upload image to OpenStack
|
||||
These example instructions are for any version of [Private Cloud Director](https://platform9.com/private-cloud-director/) - Platform9 hosted, self-hosted, or [Community Edition](https://platform9.com/docs/private-cloud-director/private-cloud-director/getting-started-with-community-edition) - but can be adapted for any OpenStack-compliant cloud.
|
||||
- Follow the instructions in _Private Cloud Director > Images > Import with CLI_ to upload the image from the command line.
|
||||
- Upload the vJailbreak qcow2 image to your image library.
|
||||
```shell
|
||||
openstack image create --os-interface admin --insecure --container-format bare --disk-format qcow2 --file <vjailbreak-image-path> vjailbreak-image.qcow2
|
||||
```
|
||||
- Set the disk bus to virtio-scsi on the uploaded image. During migrations, vJailbreak attaches the target volumes to itself for conversion; with the default virtio-blk bus each attached volume consumes a PCI slot, and migrating VMs with many disks can fail with a `No more available PCI slots` error.
|
||||
With virtio-scsi, all volumes share a single controller. See [Known Limitations](../../reference/known-limitations/#pci-slot-exhaustion-when-attaching-disks-with-virtio-blk).
|
||||
```shell
|
||||
openstack image set --property hw_disk_bus=scsi --property hw_scsi_model=virtio-scsi vjailbreak-image.qcow2
|
||||
```
|
||||
|
||||
### Create vJailbreak VM
|
||||
- Deploy a new VM from the uploaded image, choosing the _m1.xlarge.vol_ flavor (use larger flavor for larger VM migration).
|
||||
- Choose a network that can reach your VMware vCenter environment.
|
||||
- Assign a network security group that allows inbound and outbound traffic.
|
||||
|
||||
### Network Initialization
|
||||
|
||||
vJailbreak requires a valid IP address and network route to initialize properly. The installation behavior differs based on your network configuration:
|
||||
|
||||
**Standard DHCP Networks**
|
||||
|
||||
In most PCD deployments, the VM receives an IP address via DHCP immediately at boot. The vJailbreak installation proceeds automatically and the UI becomes accessible within a few minutes at `http://<vm-ip>/`.
|
||||
|
||||
**L2-Only Networks**
|
||||
|
||||
In environments where IP addresses are assigned manually after VM deployment (L2-only networks without DHCP), the vJailbreak installation follows a specific sequence. This section provides a detailed walkthrough of what to expect and how to configure the VM.
|
||||
|
||||
#### Step 1: VM Boot and Network Wait State
|
||||
|
||||
When the vJailbreak VM starts in an L2-only network, the installation script detects that no IP address is available and enters a waiting state. You will see the following behavior in the console:
|
||||
|
||||
1. The VM boots and initializes basic services
|
||||
2. The script sets a default password for the `ubuntu` user
|
||||
3. K3s master setup begins but pauses waiting for network availability
|
||||
4. The console displays repeated messages indicating it is waiting for network configuration
|
||||
|
||||
**Console output during wait state:**
|
||||
```
|
||||
[2026-03-17 10:07:59] IS_MASTER: true
|
||||
[2026-03-17 10:07:59] MASTER_IP:
|
||||
[2026-03-17 10:07:59] K3S_TOKEN:
|
||||
[2026-03-17 10:07:59] INSTALL_K3S_EXEC: server --secrets-encryption
|
||||
[2026-03-17 10:07:59] Setting default password for ubuntu user...
|
||||
[2026-03-17 10:07:59] Default password set for ubuntu user. User will need to change it on first login
|
||||
[2026-03-17 10:07:59] Setting up K3s Master...
|
||||
[2026-03-17 10:07:59] Waiting for network availability...
|
||||
[2026-03-17 10:07:59] Waiting for network: missing default route and global IPv4 address...
|
||||
[2026-03-17 10:08:59] Waiting for network: missing default route and global IPv4 address...
|
||||
[2026-03-17 10:09:59] Waiting for network: missing default route and global IPv4 address...
|
||||
```
|
||||
|
||||
The script checks every minute for:
|
||||
- A non-loopback IPv4 address assigned to a network interface
|
||||
- A default route configured in the routing table
|
||||
|
||||
**Note:** The VM is fully accessible via console during this waiting period. You can log in and configure networking while the script waits.
|
||||
|
||||
#### Step 2: Assign an IP Address
|
||||
|
||||
You can assign an IP address using one of the following methods:
|
||||
|
||||
**Option A: Using DHCP Client**
|
||||
|
||||
If your network has a DHCP server available (but wasn't configured at boot), you can request an IP:
|
||||
|
||||
```bash
|
||||
# Check current network interface status
|
||||
ip a
|
||||
|
||||
# Request IP via DHCP on the primary interface (commonly ens3 or enp0s3)
|
||||
dhclient ens3
|
||||
```
|
||||
|
||||
After running `dhclient`, verify the IP assignment:
|
||||
```bash
|
||||
ip a
|
||||
```
|
||||
|
||||
You should see output similar to:
|
||||
```
|
||||
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
|
||||
link/ether fa:16:3e:50:e9:85 brd ff:ff:ff:ff:ff:ff
|
||||
altname enp0s3
|
||||
inet 10.96.9.142/20 brd 10.96.15.255 scope global dynamic ens3
|
||||
valid_lft 8631sec preferred_lft 8631sec
|
||||
```
|
||||
|
||||
**Option B: Static IP Configuration**
|
||||
|
||||
For environments without DHCP, configure a static IP address:
|
||||
|
||||
```bash
|
||||
# Assign static IP (replace with your network details)
|
||||
sudo ip addr add 192.168.1.100/24 dev ens3
|
||||
|
||||
# Configure default gateway
|
||||
sudo ip route add default via 192.168.1.1
|
||||
|
||||
# Verify configuration
|
||||
ip a
|
||||
ip route
|
||||
```
|
||||
|
||||
**Important:** Ensure the IP address and gateway are appropriate for your network. Contact your network administrator if you're unsure about the correct values.
|
||||
|
||||
#### Step 3: Automatic Installation Proceeds
|
||||
|
||||
Once the network is configured, the installation script automatically detects the change and proceeds with the setup. You can monitor progress by tailing the installation log:
|
||||
|
||||
```bash
|
||||
tail -f /var/log/pf9-install.log
|
||||
```
|
||||
|
||||
You will see the script transition from waiting to active installation:
|
||||
```
|
||||
[2026-03-17 11:08:00] Waiting for network: missing default route and global IPv4 address...
|
||||
[2026-03-17 11:09:01] Network detected. Default route and global IPv4 address available.
|
||||
[2026-03-17 11:09:09] K3s is ready.
|
||||
[2026-03-17 11:09:10] Loading all the images in /etc/pf9/images...
|
||||
[2026-03-17 11:10:38] Applying kube-prometheus manifests...
|
||||
[2026-03-17 11:10:50] K3s master setup completed
|
||||
[2026-03-17 11:10:51] Rsync daemon started successfully.
|
||||
[2026-03-17 11:10:51] Config map created successfully.
|
||||
[2026-03-17 11:10:51] Installing cert-manager
|
||||
[2026-03-17 11:10:53] Waiting for cert-manager deployments to become available
|
||||
[2026-03-17 11:11:04] removing the cron job
|
||||
```
|
||||
|
||||
The installation performs the following steps automatically:
|
||||
1. **K3s Initialization** - Kubernetes cluster setup completes
|
||||
2. **Image Loading** - Container images are loaded from `/etc/pf9/images`
|
||||
3. **Prometheus Setup** - Monitoring stack is deployed
|
||||
4. **Rsync Daemon** - File synchronization service starts
|
||||
5. **Cert-Manager** - TLS certificate management is installed
|
||||
6. **Cleanup** - Temporary cron jobs are removed
|
||||
|
||||
#### Step 4: Access vJailbreak
|
||||
|
||||
Once installation completes (typically 2-5 minutes after network configuration), you can access vJailbreak:
|
||||
|
||||
- **UI Access:** `http://<assigned-ip>/`
|
||||
- **SSH Access:** `ssh ubuntu@<assigned-ip>` (default password: `password`)
|
||||
|
||||
#### Troubleshooting L2-Only Network Setup
|
||||
|
||||
| Issue | Solution |
|
||||
|-------|----------|
|
||||
| Script not detecting IP | Ensure both IP address AND default route are configured |
|
||||
| Installation stuck after IP assignment | Check `/var/log/pf9-install.log` for errors |
|
||||
| Cannot reach UI after installation | Verify security groups allow inbound traffic on port 80 |
|
||||
| Network interface not visible | Check VM network attachment in OpenStack dashboard |
|
||||
|
||||
**Verifying Network Readiness:**
|
||||
```bash
|
||||
# Check IP assignment
|
||||
ip addr show | grep "inet "
|
||||
|
||||
# Check default route
|
||||
ip route | grep default
|
||||
|
||||
# Both should return valid entries for installation to proceed
|
||||
```
|
||||
|
||||
### Configure VM with cloud-init
|
||||
Cloud-init can be used during VM creation to automate initial configuration including setting passwords and configuring /etc/hosts entries for DNS resolution.
|
||||
- When creating the VM, use a cloud-init configuration script to:
|
||||
- Set a password for the ubuntu user
|
||||
- Add static DNS entries to /etc/hosts
|
||||
|
||||
```yaml
|
||||
#cloud-config
|
||||
password: your-secure-password
|
||||
chpasswd: { expire: False }
|
||||
ssh_pwauth: True
|
||||
|
||||
write_files:
|
||||
- path: /etc/hosts.append
|
||||
append: true
|
||||
content: |
|
||||
# VMware and OpenStack endpoints
|
||||
192.168.1.100 vcenter.example.com
|
||||
192.168.2.100 openstack.example.com
|
||||
|
||||
runcmd:
|
||||
- cat /etc/hosts.append >> /etc/hosts
|
||||
```
|
||||
- You can provide this cloud-init configuration when creating the VM through the OpenStack dashboard or CLI.
|
||||
|
||||
**Note:** If you do not set a password for the `ubuntu` user using cloud-init, the default password for the `ubuntu` user will be set to "password." After the first login, you will be prompted to change the password and if the password is set using cloud-init you will not be prompted to change the password at first login.
|
||||
|
||||
|
||||
|
||||
### Copy VDDK Libraries (Standard Copy Only)
|
||||
|
||||
VDDK is required only if you plan to use the **Standard** storage copy method. If you are using
|
||||
**vJailbreak Accelerated Copy** or **Storage-Accelerated Copy**, skip this step; neither method
|
||||
requires VDDK.
|
||||
|
||||
:::caution[VDDK currently unavailable]
|
||||
VMware's public VDDK download pages are currently unavailable. If you do not already have a VDDK
|
||||
package, use **vJailbreak Accelerated Copy** or **Storage-Accelerated Copy** instead. Both work
|
||||
without VDDK. Note that vJailbreak Accelerated Copy supports **cold migration only** (source VM
|
||||
must be powered off before copy).
|
||||
:::
|
||||
|
||||
If you have a VDDK 8.0.x package, copy it into `/home/ubuntu` of the vJailbreak VM and untar it
|
||||
to a folder named `vmware-vix-disklib-distrib`:
|
||||
|
||||
```shell
|
||||
cd /home/ubuntu
|
||||
tar -xvf VMware-vix-disklib-8.0.3-*.x86_64.tar.gz
|
||||
# This will create the vmware-vix-disklib-distrib directory
|
||||
```
|
||||
|
||||
### Configure DNS Resolution
|
||||
Proper DNS resolution for your VMware and OpenStack URLs is required for vJailbreak to function correctly. You can either configure this during VM creation with cloud-init (as shown above) or modify the configuration after VM deployment.
|
||||
|
||||
**Important:** DNS resolution for all ESXi hosts must be properly configured in your environment. This is specifically required during the VM copy phase of migration. Without proper DNS resolution for ESXi hosts, the migration process may fail.
|
||||
|
||||
|
||||
- **Static Entries**: If you didn't configure `/etc/hosts` entries during VM creation with cloud-init, you can add them manually later.
|
||||
```shell
|
||||
# Example manual addition to /etc/hosts
|
||||
sudo sh -c 'echo "192.168.1.100 vcenter.example.com" >> /etc/hosts'
|
||||
sudo sh -c 'echo "192.168.2.100 openstack.example.com" >> /etc/hosts'
|
||||
|
||||
# ESXi hosts entries (required for VM copy phase)
|
||||
sudo sh -c 'echo "192.168.1.101 esxi01.example.com esxi01" >> /etc/hosts'
|
||||
sudo sh -c 'echo "192.168.1.102 esxi02.example.com esxi02" >> /etc/hosts'
|
||||
```
|
||||
Once the `/etc/hosts` file is modified execute below commands to apply the changes.
|
||||
```
|
||||
kubectl -n migration-system rollout restart deployment migration-controller-manager
|
||||
```
|
||||
|
||||
- **DNS Configuration**: If modifying `/etc/resolv.conf` to use DNS servers instead of static entries, restart the same `migration-controller-manager` deployment as shown above to apply the changes.
|
||||
|
||||
### Initial Access Steps
|
||||
|
||||
- **SSH Access**
|
||||
- Username: ubuntu
|
||||
- Password: password
|
||||
- Note: After you SSH, you will be prompted to change the password.
|
||||
- Example:
|
||||
```bash
|
||||
ssh ubuntu@<vjailbreak-vm-ip>
|
||||
```
|
||||
|
||||
- **UI Access**
|
||||
- URL: `http://<vjailbreak-vm-ip>/`
|
||||
- Username: admin
|
||||
- Password: password
|
||||
|
||||
### Launch vJailbreak
|
||||
- Connect to the vJailbreak UI using the IP address assigned during VM creation.
|
||||
- Add VMware and OpenStack credentials. See more here [Credential Management](../../concepts/credential-management/).
|
||||
- Select the VMs you wish to migrate and complete the rest of the migration form.
|
||||
- Migrate your VMs.
|
||||
|
||||
### Scaling vJailbreak
|
||||
<ReadMore>Read more about [scaling vJailbreak](../../guides/how-to/scaling/).</ReadMore>
|
||||
@@ -0,0 +1,197 @@
|
||||
---
|
||||
title: Prerequisites
|
||||
description: prerequisites for vJailbreak
|
||||
---
|
||||
|
||||
For frequently asked questions, see [FAQ](../faq/).
|
||||
|
||||
### VDDK requirements
|
||||
|
||||
VDDK is required only if you plan to use the **Standard** storage copy method.
|
||||
**vJailbreak Accelerated Copy** and **Storage-Accelerated Copy** do not require VDDK.
|
||||
|
||||
:::note
|
||||
VMware's public VDDK download pages are currently unavailable. If you do not already have a VDDK
|
||||
package, use vJailbreak Accelerated Copy or Storage-Accelerated Copy instead. Both work without
|
||||
VDDK. Note that vJailbreak Accelerated Copy supports **cold migration only**.
|
||||
:::
|
||||
|
||||
### What access do I need for my vCenter user to be able to perform this migration?
|
||||
|
||||
The required privileges depend on which features you use. The base set below is required for all migrations. Additional privileges are listed separately for vJailbreak Accelerated Copy and OVA-based Proxy VM deployment.
|
||||
|
||||
#### Base Privileges (all migrations)
|
||||
|
||||
| Privilege | Description |
|
||||
| --- | --- |
|
||||
| `Virtual machine.Interaction` privileges: | |
|
||||
| `Virtual machine.Interaction.Power Off` | Allows powering off a powered-on virtual machine. This operation powers down the guest operating system. |
|
||||
| `Virtual machine.Interaction.Power On` | Allows powering on a powered-off virtual machine and resuming a suspended virtual machine. |
|
||||
| `Virtual machine.Config.ChangeTracking`| Allows enabling or disabling change tracking on a virtual machine. |
|
||||
| `Virtual machine.Guest operating system management by VIX API` | Allows managing a virtual machine by the VMware VIX API. |
|
||||
| `Virtual machine.Provisioning` | Note: All `Virtual machine.Provisioning` privileges are required. |
|
||||
| `Virtual machine.Provisioning.Allow disk access` | Allows opening a disk on a virtual machine for random read and write access. Used mostly for remote disk mounting. |
|
||||
| `Virtual machine.Provisioning.Allow file access` | Allows operations on files associated with a virtual machine, including VMX, disks, logs, and NVRAM. |
|
||||
| `Virtual machine.Provisioning.Allow read-only disk access` | Allows opening a disk on a virtual machine for random read access. Used mostly for remote disk mounting. |
|
||||
| `Virtual machine.Provisioning.Allow virtual machine download` | Allows read operations on files associated with a virtual machine, including VMX, disks, logs, and NVRAM. |
|
||||
| `Virtual machine.Provisioning.Allow virtual machine files upload` | Allows write operations on files associated with a virtual machine, including VMX, disks, logs, and NVRAM. |
|
||||
| `Virtual machine.Provisioning.Clone template` | Allows cloning of a template. |
|
||||
| `Virtual machine.Provisioning.Clone virtual machine` | Allows cloning of an existing virtual machine and allocation of resources. |
|
||||
| `Virtual machine.Provisioning.Create template from virtual machine` | Allows creation of a new template from a virtual machine. |
|
||||
| `Virtual machine.Provisioning.Customize guest` | Allows customization of a virtual machine’s guest operating system without moving the virtual machine. |
|
||||
| `Virtual machine.Provisioning.Deploy template` | Allows deployment of a virtual machine from a template. |
|
||||
| `Virtual machine.Provisioning.Mark as template` | Allows marking an existing powered-off virtual machine as a template. |
|
||||
| `Virtual machine.Provisioning.Mark as virtual machine` | Allows marking an existing template as a virtual machine. |
|
||||
| `Virtual machine.Provisioning.Modify customization specification` | Allows creation, modification, or deletion of customization specifications. |
|
||||
| `Virtual machine.Provisioning.Promote disks` | Allows promote operations on a virtual machine’s disks. |
|
||||
| `Virtual machine.Provisioning.Read customization specifications` | Allows reading a customization specification. |
|
||||
| `Virtual machine.Snapshot management` privileges: | |
|
||||
| `Virtual machine.Snapshot management.Create snapshot` | Allows creation of a snapshot from the virtual machine’s current state. |
|
||||
| `Virtual machine.Snapshot management.Remove Snapshot` | Allows removal of a snapshot from the snapshot history. |
|
||||
| `Datastore` privileges: | |
|
||||
| `Datastore.Browse datastore` | Allows exploring the contents of a datastore. |
|
||||
| `Datastore.Low level file operations` | Allows performing low-level file operations - read, write, delete, and rename - in a datastore. |
|
||||
| `Sessions` privileges: | |
|
||||
| `Sessions.Validate session` | Allows verification of the validity of a session. |
|
||||
| `Cryptographic` privileges: | |
|
||||
| `Cryptographic.Decrypt` | Allows decryption of an encrypted virtual machine. |
|
||||
| `Cryptographic.Direct access` | Allows access to encrypted resources. |
|
||||
|
||||
### Additional privileges required for encrypted VMs
|
||||
|
||||
| Privilege | Purpose |
|
||||
|---|---|
|
||||
| `Cryptographer.Access` | Base access to cryptographic operations on the VM |
|
||||
| `Cryptographer.Decrypt` | Decrypt the VM's disks for read access during migration |
|
||||
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### `VixDiskLib_Open` token-retrieval failure
|
||||
|
||||
**Symptom**: Migration fails during disk open with:
|
||||
|
||||
```
|
||||
Error 1 (Unknown error): Unexpected error when trying to retrieve token for disk
|
||||
Unable to locate appropriate transport mode
|
||||
```
|
||||
|
||||
**Cause**: Missing `Cryptographer.Access` and/or `Cryptographer.Decrypt` privilege on the migration service account. This is the most common encrypted-VM permissions failure and does not surface as a permissions error in the message text.
|
||||
|
||||
**Fix**: Verify the account role includes both `Cryptographer.Access` and `Cryptographer.Decrypt`. Re-check with `govc permissions.ls` against the target VM.
|
||||
|
||||
#### Additional Privileges: vJailbreak Accelerated Copy Migrations
|
||||
|
||||
Required when using the **vJailbreak Accelerated Copy** storage copy method (VMware hot-add). vJailbreak attaches snapshot disks from the source VM to a Proxy VM and detaches them after the NBD copy completes. The controller also automatically enables `disk.EnableUUID` on the Proxy VM if it is not already set.
|
||||
|
||||
| Privilege | Description |
|
||||
| --- | --- |
|
||||
| `Virtual machine.Config.AddExistingDisk` | Allows attaching an existing VMDK (snapshot disk) to another virtual machine — used to attach source disks to the Proxy VM. |
|
||||
| `Virtual machine.Config.RemoveDisk` | Allows removing a disk from a virtual machine — used to detach source disks from the Proxy VM after copy. |
|
||||
| `Virtual machine.Config.AdvancedConfig` | Allows modifying VM extra config parameters — used to set `disk.EnableUUID = TRUE` on the Proxy VM. |
|
||||
|
||||
#### Additional Privileges: OVA-Based Proxy VM Deployment
|
||||
|
||||
Required only when using the **Deploy a new vJailbreak Proxy VM** option in the UI. These privileges are not needed if you register an existing VM as the Proxy VM.
|
||||
|
||||
| Privilege | Description |
|
||||
| --- | --- |
|
||||
| `vApp.Import` | Allows importing an OVF/OVA package into vCenter — used to deploy the pre-built Proxy VM appliance. |
|
||||
| `Datastore.AllocateSpace` | Allows allocating disk space on a datastore — used to create the Proxy VM disk files during OVA import. |
|
||||
| `Network.Assign` | Allows assigning a network to a virtual machine or vApp — used to connect the Proxy VM to the selected portgroup. |
|
||||
| `Resource.AssignVAppToPool` | Allows assigning a vApp to a resource pool — used to place the deployed Proxy VM in the target compute resource. |
|
||||
| `Virtual machine.Inventory.Create` | Allows creating a virtual machine in the vCenter inventory — used to register the Proxy VM after OVA import. |
|
||||
| `Virtual machine.Config.AdvancedConfig` | Allows modifying VM extra config parameters — used to set `disk.EnableUUID = TRUE` on the newly deployed Proxy VM. |
|
||||
|
||||
### Understanding VMware NFC Performance Limitations
|
||||
|
||||
vJailbreak uses nbdkit to transfer disk data from VMware ESXi hosts via the NFC (Network File Copy) protocol over port 902. It's important to understand the inherent performance characteristics and limitations of VMware's NFC protocol:
|
||||
|
||||
#### NFC Protocol Characteristics
|
||||
|
||||
- **Per-VMDK throughput limit**: NFC is limited to approximately **1 Gbps per VMDK** due to VMware's internal implementation
|
||||
- **Single-threaded**: NFC operations are single-threaded, limiting performance to what a single thread can achieve
|
||||
- **Encrypted by default**: NFC traffic is SSL-encrypted, which adds overhead (disabling SSL can improve speed by up to 20% but reduces security)
|
||||
- **Synchronous operations**: NFC must complete READ/WRITE/CHECK operations sequentially before proceeding
|
||||
- **Latency-aware throttling**: NFC will automatically throttle when network latency increases
|
||||
|
||||
#### Impact on vJailbreak Migrations
|
||||
|
||||
- **Per-disk transfer speed**: Each VMDK transfers at approximately 1 Gbps (125 MB/s), regardless of available network bandwidth
|
||||
- **Network saturation**: Multiple parallel VM migrations can saturate network links (e.g., a 10 Gbps link can theoretically support ~10 concurrent VM migrations)
|
||||
- **Migration time estimation**: Expect transfer times of approximately 8-9 minutes per 100 GB per VMDK
|
||||
|
||||
#### Recommendations
|
||||
|
||||
- Plan migration schedules accounting for the ~1 Gbps per-VMDK limitation
|
||||
- For VMs with large single disks, migration time will be constrained by NFC throughput rather than network capacity
|
||||
- Use parallel migrations across multiple VMs to better utilize available network bandwidth
|
||||
- Monitor network utilization to optimize the number of concurrent migrations
|
||||
- Consider scheduling large VM migrations during maintenance windows
|
||||
|
||||
|
||||
**References:**
|
||||
- [Veeam Forum: 1Gbit/s per VMDK Limit](https://forums.veeam.com/vmware-vsphere-f24/1gbit-s-per-vmdk-limit-t66468.html)
|
||||
- [Broadcom KB: NFC Performance](https://knowledge.broadcom.com/external/article/307001/nfc-performance-is-slow.html)
|
||||
|
||||
### What ports do I need to open for vJailbreak to work?
|
||||
Please refer the following table for the required ports:
|
||||
|
||||
| Port | Protocol | Source | Destination | Purpose |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 443 | TCP | PCD nodes | VMware vCenter API endpoint | VMware provider inventory<br><br>Disk transfer authentication |
|
||||
| 443 | TCP | PCD nodes | VMware ESXi hosts | Disk transfer authentication |
|
||||
| 902 | TCP | PCD nodes | VMware ESXi hosts | Disk transfer data copy via NFC protocol (see NFC limitations above) |
|
||||
| 22 | TCP | vJailbreak VM | Proxy VM | vJailbreak Accelerated Copy only: SSH control of the Proxy VM |
|
||||
| 10809–11808 | TCP | vJailbreak VM | Proxy VM | vJailbreak Accelerated Copy only: `qemu-nbd` disk transfer (one port per disk copied in parallel) |
|
||||
|
||||
|
||||
### What network connectivity do I need for vJailbreak?
|
||||
|
||||
During normal migration operations, vJailbreak only requires connectivity to vCenter, ESXi hosts, and the OpenStack API. The additional endpoints listed below are needed only when **installing or upgrading vJailbreak** itself.
|
||||
|
||||
#### Required for Migration (always)
|
||||
|
||||
The vJailbreak VM and any helper nodes must be able to reach:
|
||||
|
||||
- **vCenter and ESXi hosts** — for VM inventory, disk transfer authentication, and NFC data copy (ports 443 and 902)
|
||||
- **OpenStack API endpoints** — for creating volumes, networks, and VM resources at the destination
|
||||
- **ICMP (ping) access to guest VM IPs** — for post-migration connectivity verification (health checks)
|
||||
- **Health-check endpoints on migrated guest VMs** — over user-defined HTTP/HTTPS ports, if health checks are enabled
|
||||
|
||||
#### Required for Installation and Upgrades Only
|
||||
|
||||
The following endpoints are accessed during first-time installation or when upgrading vJailbreak. They are **not** required during normal migration operations:
|
||||
|
||||
- **Virtio ISO download source** (for Windows driver injection):
|
||||
- [https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso](https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso)
|
||||
- **Cloud-init certificate endpoints**
|
||||
- **External tooling sources**:
|
||||
- [https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/main/bundle.yaml](https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/main/bundle.yaml)
|
||||
- [https://github.com/cert-manager/cert-manager/releases/download/v1.12.0/cert-manager.yaml](https://github.com/cert-manager/cert-manager/releases/download/v1.12.0/cert-manager.yaml)
|
||||
- **K3s installation sources**:
|
||||
- [https://get.k3s.io](https://get.k3s.io)
|
||||
- [https://github.com/k3s-io/k3s](https://github.com/k3s-io/k3s)
|
||||
- [https://update.k3s.io](https://update.k3s.io)
|
||||
- [https://github.com/rancher/k3s-root](https://github.com/rancher/k3s-root)
|
||||
- **Helm chart repository for NGINX ingress**:
|
||||
- [https://kubernetes.github.io/ingress-nginx](https://kubernetes.github.io/ingress-nginx)
|
||||
- **Container registries** — for K3s, vJailbreak components (controller, UI), Prometheus, Grafana, CoreDNS, NGINX ingress, exporters:
|
||||
- [https://docker.io](https://docker.io)
|
||||
- [https://ghcr.io](https://ghcr.io)
|
||||
- [https://quay.io](https://quay.io)
|
||||
- [https://registry.k8s.io](https://registry.k8s.io)
|
||||
|
||||
|
||||
|
||||
|
||||
### Required Ingress Rules for Kubernetes Node with Kubelet, Metrics Server, and Prometheus
|
||||
|
||||
| **Component** | **Port** | **Protocol** | **Source** | **Purpose** |
|
||||
|--------------------|----------|-------------|------------|-------------|
|
||||
| **Kubelet API** | 10250 | TCP | Control Plane / Prometheus | Health checks, logs, metrics |
|
||||
| **Kubelet Read-Only (Optional)** | 10255 | TCP | Internal Only | Deprecated but might be used in some cases |
|
||||
| **Metrics Server** | 4443 | TCP | Internal Cluster | K8s resource metrics (`kubectl top`) |
|
||||
| **Prometheus** | 9090 | TCP | Internal Cluster / Monitoring Server | Prometheus UI and API |
|
||||
| **Node Exporter** (if used) | 9100 | TCP | Prometheus | Node-level metrics |
|
||||
| **Cadvisor (Optional)** | 4194 | TCP | Internal Cluster / Prometheus | Container metrics collection |
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: What is vJailbreak?
|
||||
description: Introduction to vJailbreak
|
||||
---
|
||||
|
||||
[vJailbreak](https://github.com/platform9/vjailbreak) is an open-source tool featuring a user-friendly interface designed to simplify and accelerate the migration of virtual machines (VMs) __from VMware vSphere__ environments to any [Platform9 Private Cloud Director](https://platform9.com/private-cloud-director/) OR any __OpenStack-compliant__ cloud. It eliminates the complexities of cross-platform VM migration, enabling you to modernize your infrastructure with minimal disruption and a streamlined, visual workflow.
|
||||
|
||||
### How vJailbreak works
|
||||
|
||||
vJailbreak's intuitive interface leverages the OpenStack & VMware SDKs to interact directly with both your VMware vSphere environment and your target OpenStack cloud. The UI guides you through these key steps:
|
||||
|
||||
1. **Connection Setup:** Easily configure connections to your source VMware vSphere environment and your target OpenStack cloud.
|
||||
2. **VM Selection:** Select the VMs you wish to migrate from your vSphere environment.
|
||||
3. **Migration Planning:** Configure migration settings, such as target storage and network configurations, through interactive forms.
|
||||
4. **Migration Execution:** Initiate and monitor the migration process with real-time progress updates.
|
||||
5. **Post-Migration Validation:** Verify the successful migration and launch of your VMs in OpenStack.
|
||||
|
||||
### Key features
|
||||
|
||||
* **Intuitive User Interface:** Manage the entire migration process through a clear, easy-to-use graphical interface – no command-line expertise required.
|
||||
* **Seamless vCenter Integration:** Easily connect to your VMware vCenter to manage and migrate VMs.
|
||||
* **Effortless VM Selection:** Select the virtual machines you wish to migrate with just a few clicks.
|
||||
* **Automated Disk Conversion:** VM disks are automatically converted from `vmdk` to `qcow2` format.
|
||||
* **Driver and Device Installation:** Necessary virtual devices and drivers are installed to ensure smooth operation post-migration.
|
||||
* **Post-Migration Health Checks:** Comprehensive health checks are performed to verify the success of the migration and the operational status of the VMs in the new environment.
|
||||
### Key benefits
|
||||
* **Reduced Migration Time:** Automate migration tasks and visualize progress, significantly reducing the time and effort compared to manual methods.
|
||||
* **Minimized Downtime:** vJailbreak's efficient migration process helps minimize downtime for your critical workloads.
|
||||
* **Cost-Effective Solution:** As an open-source tool, vJailbreak eliminates licensing costs.
|
||||
* **Broad Compatibility:** Migrate VMs to any OpenStack cloud that adheres to standard OpenStack APIs.
|
||||
* **Non-Disruptive Migration:** Perform migrations without impacting the operation of your source VMware environment.
|
||||
* **Visual Progress Tracking:** Monitor the status of your migrations in real-time through the user interface.
|
||||
|
||||
:::tip[Did you know?]
|
||||
By leveraging vJailbreak, organizations can modernize their infrastructure with minimal disruption, ensuring a smooth transition to an OpenStack cloud.
|
||||
:::
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: vJailbreak Compatibility
|
||||
description: A list of supported VMware and operating system versions.
|
||||
---
|
||||
|
||||
Following is a list of systems vJailbreak has been validated with. Please reach out to us to report any issues or to add support for additional versions.
|
||||
|
||||
## VMware
|
||||
|
||||
* VMware vCenter Server 6.7
|
||||
* VMware vCenter Server 7.0
|
||||
* VMware vCenter Server 8.0
|
||||
|
||||
## Operating System
|
||||
|
||||
The list of operating system is large and while we have attempted
|
||||
to test some of them, there are still gaps specifically with the older
|
||||
versions. This list is expected to grow over time and we will continue to
|
||||
add support for additional versions. Verified implies it has been tested and converted vs expected means it has not been tested but is expected to work.
|
||||
|
||||
|
||||
| Operating System | Platform | Verified | Expected |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| AlmaLinux | linux/amd64 | No | Yes |
|
||||
| Amazon Linux 2 | linux/amd64 | No | Yes |
|
||||
| CentOS 4/5 | linux/i386 | No | Yes |
|
||||
| CentOS 4 | linux/amd64 | No | Yes |
|
||||
| CentOS 5 | linux/amd64 | Yes | Yes |
|
||||
| CentOS 6 | linux/amd64 | Yes | Yes |
|
||||
| CentOS 7 | linux/amd64 | Yes | Yes |
|
||||
| CentOS 8 | linux/amd64 | Yes | Yes |
|
||||
| CentOS 9 | linux/amd64 | Yes | Yes |
|
||||
| CentOS Stream10 | linux/amd64 | No | Yes |
|
||||
| Debian GNU/Linux 8 (64-bit) | linux/amd64 | No | Yes |
|
||||
| Debian 12 | linux/amd64 | Yes | Yes |
|
||||
| FreeBSD 14 | bsd/amd64 | Yes | Yes |
|
||||
| Microsoft Windows 11 | windows/amd64 | Yes | Yes |
|
||||
| Microsoft Windows 11 Enterprise | windows/amd64 | Yes | Yes |
|
||||
| Microsoft Windows Server 2012 | windows/amd64 | Yes | Yes |
|
||||
| Microsoft Windows Server 2016 | windows/amd64 | Yes | Yes |
|
||||
| Microsoft Windows Server 2019 | windows/amd64 | Yes | Yes |
|
||||
| Microsoft Windows Server 2022 | windows/amd64 | Yes | Yes |
|
||||
| Microsoft Windows Server 2025 | windows/amd64 | Yes | Yes |
|
||||
| Oracle Linux 7 | linux/amd64 | No | Yes |
|
||||
| Oracle Linux 8 | linux/amd64 | Yes | Yes |
|
||||
| Red Hat Enterprise Linux 10 | linux/amd64 | Yes | Yes |
|
||||
| Red Hat Enterprise Linux 8 | linux/amd64 | Yes | Yes |
|
||||
| Red Hat Enterprise Linux 9 | linux/amd64 | Yes | Yes |
|
||||
| Red Hat Enterprise Linux 7 | linux/amd64 | No | Yes |
|
||||
| Red Hat Enterprise Linux 5 | linux/amd64 | No | Yes |
|
||||
| Red Hat Enterprise Linux 4 | linux/amd64 | No | Yes |
|
||||
| Rocky 8 | linux/amd64 | Yes | Yes |
|
||||
| Rocky 9 | linux/amd64 | Yes | Yes |
|
||||
| Rocky 10 | linux/amd64 | Yes | Yes |
|
||||
| SUSE Linux Enterprise 15 | linux/amd64 | Yes | Yes |
|
||||
| Ubuntu Linux 14 | linux/amd64 | Yes | Yes |
|
||||
| Ubuntu Linux 15 | linux/amd64 | Yes | Yes |
|
||||
| Ubuntu Linux 16 | linux/amd64 | Yes | Yes |
|
||||
| Ubuntu Linux 17 | linux/amd64 | Yes | Yes |
|
||||
| Ubuntu Linux 22.04 | linux/amd64 | Yes | Yes |
|
||||
| Ubuntu Linux 24.04 | linux/amd64 | Yes | Yes |
|
||||
| VMware Photon OS | linux/amd64 | No | No |
|
||||
|
||||
|
||||
@@ -0,0 +1,293 @@
|
||||
---
|
||||
title: Known Limitations
|
||||
description: Known limitations and unsupported configurations in vJailbreak
|
||||
---
|
||||
|
||||
This page documents known limitations, unsupported configurations, and important caveats in vJailbreak. Review this page before planning a migration to avoid unexpected failures.
|
||||
|
||||
## Windows Dynamic Disk (LDM)
|
||||
|
||||
Windows VMs whose **system volume** sits on a **dynamic disk** (Logical Disk Manager / LDM) are supported, but they follow a dedicated migration path. `virt-v2v` cannot convert these guests, so vJailbreak skips conversion, brings the VM up on an emulated SATA controller, and waits at the **LDM Boot Verification** phase for you to move it to virtio.
|
||||
|
||||
vJailbreak detects this automatically — there is nothing to select in the migration form.
|
||||
|
||||
| Configuration | Result |
|
||||
|---|---|
|
||||
| Root: Basic, Data: LDM | Migrates normally — import LDM data disks in Windows post-migration |
|
||||
| Root: LDM, Data: Basic | Supported via the SATA-first path — manual cutover required |
|
||||
| Root: LDM, Data: LDM | Supported via the SATA-first path — manual cutover required |
|
||||
|
||||
The following limitations apply when the system volume is on LDM:
|
||||
|
||||
| Limitation | Detail |
|
||||
|---|---|
|
||||
| Conversion-time features do not run | **VMware Tools removal**, **network persistence** and **user firstboot scripts** are all performed by `virt-v2v` during conversion. Conversion is skipped, so these must be handled manually inside the guest. |
|
||||
| VirtIO drivers must be pre-installed | Drivers cannot be injected offline into an LDM volume. Install the VirtIO guest tools on the **source** VM before migrating. |
|
||||
| The SAN policy must be set beforehand | Without `san policy=onlineall`, Windows brings the migrated disks up offline and the LDM volume set is left broken. |
|
||||
| The migration requires manual intervention | The migration pauses at **LDM Boot Verification** until you confirm the VM booted. There is no timeout, so the migration will not complete unattended. |
|
||||
|
||||
See the full guide: [Windows Dynamic Disk (LDM) Migration](../../guides/how-to/windows-ldm-migration/).
|
||||
|
||||
## Active Directory-Joined VMs
|
||||
|
||||
### Domain Controllers
|
||||
|
||||
Migrating Active Directory Domain Controller VMs is **strongly not recommended**. The core risk is specific to how vJailbreak works: `virt-v2v` performs a disk-level conversion and creates a new VM on a different hypervisor. **VM-GenerationID** — the hypervisor metadata that Windows Server 2012+ uses to detect unsafe restores — is not stored on disk and is not preserved through this process. The migrated DC starts with a new (or absent) VMGenID, which Windows AD treats as an unsafe restore/clone.
|
||||
|
||||
What happens depends on the Windows version:
|
||||
|
||||
- **Windows Server 2012 and later**: The lost VMGenID triggers Windows' built-in safeguards. The DC automatically resets its invocation ID and forces a non-authoritative resync against replication partners. The domain may recover if other DCs are reachable, but this is unreliable in production and is not a supported migration path.
|
||||
- **Windows Server 2008 R2 and earlier** (no VMGenID support): A genuine **USN rollback** can occur. The domain silently stops accepting replication from the migrated DC, and the AD environment can diverge without obvious errors. This is difficult to detect and hard to recover from.
|
||||
|
||||
In both cases the **source DC must be permanently removed from the domain** before or immediately after the migrated copy is brought online. Running both simultaneously on the same domain will corrupt AD.
|
||||
|
||||
**Recommended approach** (from [Microsoft guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/detect-and-recover-from-usn-rollback)):
|
||||
|
||||
1. **Provision a new DC** in the target OpenStack environment using standard AD promotion.
|
||||
2. **Let AD replication populate it** from an existing domain controller.
|
||||
3. **Decommission the source DC** via `dcpromo` or Server Manager once replication is verified complete.
|
||||
|
||||
**If you must migrate a DC** (lab/test environments, single-DC setups with no alternative), take these precautions:
|
||||
|
||||
- Cleanly shut down the source DC before migration — do not snapshot a running DC.
|
||||
- Migrate only one DC at a time.
|
||||
- After the migrated DC boots, verify replication health immediately:
|
||||
```cmd
|
||||
repadmin /replsummary
|
||||
dcdiag /test:replications
|
||||
```
|
||||
- Confirm time synchronization (Kerberos requires clocks within 5 minutes of each other).
|
||||
- Verify DNS is resolving correctly for all domain members.
|
||||
- Decommission the source DC immediately — never run the original and migrated DC on the same domain simultaneously.
|
||||
|
||||
### Member Servers and Workstations
|
||||
|
||||
Migrating domain-joined **member VMs** (non-DC servers and workstations) is generally safe. The machine account password is stored in the VM's own LSA secrets and is copied with the disk, so domain membership typically survives the migration intact.
|
||||
|
||||
A few edge cases can cause domain authentication to fail post-migration:
|
||||
|
||||
- **Kerberos clock skew**: If the migrated VM's clock is more than 5 minutes off from the domain controller, Kerberos authentication will fail. Sync the VM's clock immediately after boot.
|
||||
- **DNS resolution failures**: The VM must be able to resolve the domain controller's name and locate AD SRV records. Verify DNS settings after migration.
|
||||
- **Pre-existing stale computer account**: If the source VM had been offline for an extended period (typically 90+ days) before migration, the domain controller may have already invalidated its computer account. This is a pre-existing condition unrelated to the migration itself.
|
||||
|
||||
If users see `The trust relationship between this workstation and the primary domain failed` after migration, run the following to reset the account:
|
||||
|
||||
```powershell
|
||||
# Option 1 — reset computer account password without rejoining
|
||||
netdom resetpwd /server:<domain-controller> /userd:<domain\admin> /passwordd:*
|
||||
|
||||
# Option 2 — rejoin the domain
|
||||
Remove-Computer -WorkgroupName WORKGROUP -Force
|
||||
Add-Computer -DomainName <domain> -Credential <domain\admin> -Restart
|
||||
```
|
||||
|
||||
## Persist Network: Windows Server 2012 and Below
|
||||
|
||||
The **Persist source network interfaces** option does not work for Windows Server 2012 and earlier (including Windows Server 2008 R2 and Windows Server 2008).
|
||||
|
||||
Network interface name persistence depends on PowerShell capabilities, the Windows registry structure for network adapters, and a compatible version of `pnputil`. These prerequisites are not met on Windows Server 2012 and earlier.
|
||||
|
||||
**Workaround**: Manually reconfigure network interface names and static IP settings inside the VM after migration.
|
||||
|
||||
## Assign IP and Persist Network Cannot Be Used Together
|
||||
|
||||
The **Assign IP** and **Persist Network** (Persist source network interfaces) options are mutually exclusive. Enabling both simultaneously produces undefined behavior and the migration may not apply either setting correctly.
|
||||
|
||||
**Rule**: Use one or the other — not both.
|
||||
|
||||
- Use **Assign IP** when you need to set a specific IP address on the destination VM.
|
||||
- Use **Persist Network** when you need to preserve the source VM's interface names and static routes.
|
||||
|
||||
## Multi-IP Assignment Not Supported
|
||||
|
||||
Only one IP address per network interface is supported in the **Assign IPs** field. The UI enforces this — the field accepts a single IP per interface. If multiple IPs are specified via CLI, the migration will fail.
|
||||
|
||||
**Workaround**: Assign additional IPs manually inside the VM after migration, or use OpenStack port configuration to attach additional floating IPs post-migration.
|
||||
|
||||
## VMware Tools Removal: Residual Artifacts
|
||||
|
||||
The VMware Tools removal process performed by `virt-v2v` during migration may leave behind residual files and registry entries on the destination VM.
|
||||
|
||||
These artifacts are typically harmless but may appear in application logs or security scans.
|
||||
|
||||
For a full list of known residual artifacts and cleanup steps, see: [VMware Residual Artifacts](../../guides/troubleshooting/vmware_residual_artifacts/).
|
||||
|
||||
## Multi-Boot VMs Not Supported
|
||||
|
||||
vJailbreak does not support VMs with **multiple bootable operating systems** (multi-boot configurations). `virt-v2v` inspects only a single OS installation per VM and cannot convert multi-boot disk layouts.
|
||||
|
||||
**Workaround**: Migrate each OS as a separate VM, or convert the disk to a single-boot configuration before migration.
|
||||
|
||||
## SUSE Linux (SLES / SLED) with Legacy GRUB 0.97
|
||||
|
||||
Older SUSE-family VMs — **SLES**, **SLED**, and other **SUSE** distributions — that still boot with **legacy GRUB (0.97)** require special handling. These are typically BIOS VMs on a multi-disk layout, where the first boot stage sits in one disk's MBR while its second stage and `/boot` live on a separate disk. After migration to KVM, the virtual disks are re-numbered and no longer match the original VMware ordering, so GRUB cannot find its second stage and the VM fails to boot with `GRUB Error 21`.
|
||||
|
||||
In such scenarios, we recommend upgrading to GRUB2.
|
||||
|
||||
**Why we upgrade GRUB**: GRUB 0.97 is too old and fragile — it hard-codes disk numbers and block offsets that break the moment the hypervisor re-orders disks. `virt-v2v` also can't reconfigure GRUB 0.97 for KVM; it only manages GRUB2.
|
||||
|
||||
NOTE: On these older SUSE releases GRUB2 ships only as an EFI build (no legacy-BIOS version), so upgrading GRUB forces a switch to UEFI.
|
||||
|
||||
## RHEL 7 Guests Missing GRUB Compatibility Symlink
|
||||
|
||||
Some RHEL 7.x guests are missing the `/boot/grub/grub.cfg` compatibility symlink that `grubby` (used internally by `virt-v2v-in-place`) expects to point at `/boot/grub2/grub.cfg`. GRUB2 itself is configured correctly — only this symlink is missing — and conversion fails with:
|
||||
|
||||
```text
|
||||
libguestfs error: command:
|
||||
error opening /boot/grub/grub.cfg for read:
|
||||
No such file or directory
|
||||
```
|
||||
|
||||
**Workaround**: Verify and, if needed, recreate the symlink before migrating. See [virt-v2v-in-place fails on RHEL 7](../../guides/troubleshooting/troubleshooting/#virt-v2v-in-place-fails-on-rhel-7-missing-grub-compatibility-symlink) for details.
|
||||
|
||||
## Hotplug Flavor Requirements
|
||||
|
||||
OpenStack **hotplug** (live CPU/RAM resize without VM reboot) is supported post-migration, but only if the VM is migrated with a hotplug-capable flavor.
|
||||
|
||||
To use hotplug after migration:
|
||||
|
||||
1. **Platform9 Private Cloud Director (PCD)**: PCD provides a hotplug base flavor named `hotplug` by default. While triggering the migration in vJailbreak, select the `hotplug` flavor for the VMs that need live resize.
|
||||
|
||||
2. **Other OpenStack environments**: ask your OpenStack admin to create a flavor with hotplug-enabled extra specs, for example:
|
||||
|
||||
```bash
|
||||
openstack flavor set <flavor-name> \
|
||||
--property hw:cpu_policy=mixed \
|
||||
--property hw:cpu_max_vcpus=<max> \
|
||||
--property hw:mem_page_size=any
|
||||
```
|
||||
|
||||
Then assign this flavor in the vJailbreak migration form before starting the migration.
|
||||
3. After migration, resize the VM in OpenStack using the hotplug capability.
|
||||
|
||||
### Hotplug Metadata and Resize Headroom
|
||||
|
||||
When a hotplug base flavor (0 vCPU, 0 RAM — such as PCD's default `hotplug` flavor) is assigned, vJailbreak creates the target VM with the following server metadata:
|
||||
|
||||
| Metadata key | Value |
|
||||
|---|---|
|
||||
| `HOTPLUG_CPU` | Source VM's current vCPU count |
|
||||
| `HOTPLUG_MEMORY` | Source VM's current memory (MB) |
|
||||
| `HOTPLUG_CPU_MAX` | **2x** the source VM's vCPU count |
|
||||
| `HOTPLUG_MEMORY_MAX` | **2x** the source VM's memory (MB) |
|
||||
|
||||
The max keys define the ceiling for post-migration live resize. They are set to twice the source VM's size so the migrated VM has hotplug headroom out of the box — for example, a VM migrated with 2 vCPUs and 4096 MB RAM can be live-resized up to 4 vCPUs and 8192 MB RAM.
|
||||
|
||||
:::caution
|
||||
Hotplug metadata can only be set at VM creation time and cannot be modified afterward. To resize beyond the 2x ceiling, the VM must be recreated.
|
||||
:::
|
||||
|
||||
:::note
|
||||
Standard flavors without hotplug extra specs will not support live resize. The VM must be powered off for a cold resize in that case.
|
||||
:::
|
||||
|
||||
## PCI Slot Exhaustion When Attaching Disks with virtio-blk
|
||||
|
||||
During conversion, vJailbreak attaches the target volumes to the vJailbreak VM (or its agent VMs). If the vJailbreak image is uploaded without a disk bus setting, OpenStack uses the default **virtio-blk** bus, where every attached volume consumes its own PCI slot. Migrating VMs with many disks, or running many parallel migrations on one agent, Maximum 26 devices can be attached after which PCI slots will exhaust and volume attach fails with:
|
||||
|
||||
```text
|
||||
libvirt.libvirtError: internal error: No more available PCI slots
|
||||
```
|
||||
|
||||
**Workaround**: Set the disk bus to **virtio-scsi** on the vJailbreak image before creating the vJailbreak VM. All attached volumes then share a single SCSI controller (one PCI slot, up to 256 devices):
|
||||
|
||||
```bash
|
||||
openstack image set \
|
||||
--property hw_disk_bus=scsi \
|
||||
--property hw_scsi_model=virtio-scsi \
|
||||
<vjailbreak-image-name-or-ID>
|
||||
```
|
||||
|
||||
:::note
|
||||
The disk bus is fixed when the VM is created. If the vJailbreak VM is already deployed, recreate it from the updated image. Agent VMs created during scale up use the same image, so set these properties before scaling up.
|
||||
:::
|
||||
|
||||
See the full troubleshooting entry: [Disk attach fails during migration: No more available PCI slots](../../guides/troubleshooting/troubleshooting/#disk-attach-fails-during-migration-no-more-available-pci-slots).
|
||||
|
||||
## Low Disk Space in the Source VM
|
||||
|
||||
Before starting conversion, `virt-v2v` checks that each filesystem inside the **source VM** has sufficient free space. If any filesystem is too full, the conversion fails before it begins.
|
||||
|
||||
Minimum free space required inside the source VM ([source: virt-v2v docs](https://libguestfs.org/virt-v2v.1.html)):
|
||||
|
||||
| Filesystem | Minimum free space |
|
||||
|---|---|
|
||||
| Linux root (`/`) | 100 MB |
|
||||
| Linux `/boot` | 50 MB (needed to rebuild initramfs) |
|
||||
| Windows `C:` drive | 100 MB (virtio drivers and guest agents are copied in) |
|
||||
| Any other mountable filesystem | 10 MB |
|
||||
|
||||
Each filesystem must also have at least **100 free inodes**.
|
||||
|
||||
**Workaround**: Before migrating, free up space inside the source VM on any full partitions. Check with `df -h` (Linux) or Disk Management (Windows).
|
||||
|
||||
## Hot Migration Requires Virtual Hardware Version 7 or Newer
|
||||
|
||||
vJailbreak **Hot migration** (**Copy live VMs, then power off**) relies on VMware **Changed Block Tracking (CBT)** to copy only changed disk blocks during the live sync phase. CBT is available only on VMs running **virtual hardware version 7 or newer** (VMware KB 1020128).
|
||||
|
||||
VMs on older hardware versions (for example, version 4) do not expose the CBT property at all, so Hot migration cannot track changed blocks for them.
|
||||
|
||||
**Symptom**: A Hot migration of a legacy-hardware VM fails at the CBT step. The reported error looks similar to:
|
||||
|
||||
```
|
||||
CBT is not enabled on disk <id>
|
||||
```
|
||||
|
||||
**What to do** — choose one:
|
||||
|
||||
1. **Use cold migration** (**Power off VMs, then copy**) for these VMs. Cold migration copies each disk once in full while the VM is powered off and does not use CBT, so it works on any hardware version. *(Recommended — requires no changes to the source VM.)*
|
||||
2. **Upgrade the VM's virtual hardware version** to 7 or newer in vCenter, then use Hot migration if you need minimal downtime. Upgrading the hardware version requires a VM power-off and cannot be reversed — review VMware's documentation before proceeding.
|
||||
|
||||
| VM virtual hardware version | Hot migration | Cold migration |
|
||||
|---|---|---|
|
||||
| 7 or newer | Supported | Supported |
|
||||
| Below 7 (e.g., version 4) | Not supported — use cold migration | Supported |
|
||||
|
||||
:::note
|
||||
To check a VM's hardware version in vCenter, select the VM and look at **VM Hardware → Compatibility** (shown as "ESXi X.X and later (VM version N)").
|
||||
:::
|
||||
|
||||
## vJailbreak Accelerated Copy
|
||||
|
||||
The limitations below are specific to [vJailbreak Accelerated Copy](../../concepts/vjailbreak-accelerated-copy/). See its [full limitations list](../../concepts/vjailbreak-accelerated-copy/#limitations) for the remaining constraints.
|
||||
|
||||
### Concurrent Disk Attach Can Fail
|
||||
|
||||
When several migrations reach the disk-attach step at the same time on the same Proxy VM, vCenter does not always handle the simultaneous reconfigure tasks gracefully and rejects some attach requests, failing those migrations. This is a **transient race condition** — the migrations that attached first are unaffected and continue into the copy phase.
|
||||
|
||||
**Workaround**: [Retry](../../guides/how-to/retry_failed_migration/) the failed migrations once the others have moved into the copy phase. To reduce the chance of the race, stagger migration start times or distribute migrations across additional Proxy VMs.
|
||||
|
||||
See [Proxy VM disk attach fails when several migrations start together](../../guides/troubleshooting/troubleshooting/#proxy-vm-disk-attach-fails-when-several-migrations-start-together).
|
||||
|
||||
### Proxy VM Must Use a PVSCSI Controller
|
||||
|
||||
vJailbreak matches each attached snapshot disk to a block device inside the Proxy VM by disk UUID, which works only on the **VMware Paravirtual (PVSCSI)** controller. The Proxy VM's **SCSI controller 0** must be PVSCSI — LSI Logic SAS, LSI Logic Parallel, and BusLogic Parallel are not supported. Migrations using any other type fail with `could not identify block device for disk <uuid>`.
|
||||
|
||||
**Workaround**: Power off the Proxy VM and set **Edit Settings** → **SCSI controller 0** → **Change Type** → **VMware Paravirtual** before registering it in vJailbreak.
|
||||
|
||||
See [Configure the SCSI Controller Type on the Proxy VM](../../concepts/vjailbreak-accelerated-copy/#configure-the-scsi-controller-type-on-the-proxy-vm) and [could not identify block device](../../guides/troubleshooting/troubleshooting/#vjailbreak-accelerated-copy-fails-could-not-identify-block-device).
|
||||
|
||||
## Application Reboot During Migration
|
||||
|
||||
Cold migration (**Power off VMs, then copy**) powers off the source VM before copying its disk. The destination VM boots fresh after migration completes. **Applications must tolerate a reboot** — any in-memory state, open transactions, or non-persistent connections will be lost.
|
||||
|
||||
Hot migration (**Copy live VMs, then power off**) minimizes downtime but still requires a brief power-off during the final cutover phase to synchronize the last changed blocks. Applications should be tested for graceful handling of this cutover reboot.
|
||||
|
||||
:::caution
|
||||
Before migrating, verify that your application starts cleanly after a cold reboot. Applications that require manual intervention to restart (e.g., databases with crash-inconsistent state) should be cleanly shut down inside the VM before initiating cold migration.
|
||||
:::
|
||||
|
||||
## Retrying a Failed Migration
|
||||
|
||||
The **Retry** action reopens a failed migration in the migration form so its configuration can be corrected. The following limitations apply. See [Retry a Failed Migration](../../guides/how-to/retry_failed_migration/) for the full workflow.
|
||||
|
||||
| Limitation | Detail |
|
||||
|---|---|
|
||||
| VMs with RDM disks cannot be retried | Shared RDM disk state prevents an automatic retry. The Retry button is disabled for these migrations and the migration must be restarted manually. |
|
||||
| A retry always produces a single-VM plan | Retrying one VM from a plan that covered several VMs moves that VM into a plan of its own. The remaining VMs stay in the original plan and are unaffected. |
|
||||
| Bulk retry cannot change configuration | **Retry Selected** restarts each migration with its existing configuration. To change settings, retry the migration individually. |
|
||||
| Credentials and source cluster are locked | A retry cannot change the VMware or OpenStack credentials or the source cluster. Create a new migration instead. |
|
||||
|
||||
:::note
|
||||
Changing the target PCD cluster during a retry clears the network and storage mappings, because mappings are specific to a cluster. Select new mappings before submitting.
|
||||
:::
|
||||
@@ -0,0 +1,252 @@
|
||||
---
|
||||
title: vJailbreak CRD references
|
||||
description: A helpful explaination of the Kubernetes custom resource definitions (CRD) that vJailbreak uses.
|
||||
---
|
||||
The following custom resource definitions (CRD) are deployed in the same namespace as the Migration Controller pod. By default, the namespace is `migration-system`.
|
||||
|
||||
## Credentials
|
||||
### OpenStack
|
||||
- OpenstackCreds use the variables from the openstack.rc file. All fields are required except `OS_INSECURE`
|
||||
```yaml
|
||||
apiVersion: vjailbreak.k8s.pf9.io/v1alpha1
|
||||
kind: OpenstackCreds
|
||||
metadata:
|
||||
name: osc1
|
||||
namespace: migration-system
|
||||
spec:
|
||||
secretRef:
|
||||
name: osc1-openstack-secret
|
||||
---
|
||||
apiVersion: v1
|
||||
data:
|
||||
OS_AUTH_URL:
|
||||
OS_DOMAIN_NAME:
|
||||
OS_INSECURE:
|
||||
OS_PASSWORD:
|
||||
OS_REGION_NAME:
|
||||
OS_TENANT_NAME:
|
||||
OS_USERNAME:
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: osc1-openstack-secret
|
||||
namespace: migration-system
|
||||
type: Opaque
|
||||
```
|
||||
### VMware
|
||||
- All fields in VMwareCreds are required.
|
||||
```yaml
|
||||
apiVersion: vjailbreak.k8s.pf9.io/v1alpha1
|
||||
kind: VMwareCreds
|
||||
metadata:
|
||||
name: vmc1
|
||||
namespace: migration-system
|
||||
spec:
|
||||
secretRef:
|
||||
name: vmc1-vmware-secret
|
||||
---
|
||||
apiVersion: v1
|
||||
data:
|
||||
VCENTER_HOST:
|
||||
VCENTER_INSECURE:
|
||||
VCENTER_PASSWORD:
|
||||
VCENTER_USERNAME:
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: vmc1-vmware-secret
|
||||
namespace: migration-system
|
||||
type: Opaque
|
||||
```
|
||||
## Network mapping
|
||||
```yaml
|
||||
apiVersion: vjailbreak.k8s.pf9.io/v1alpha1
|
||||
kind: NetworkMapping
|
||||
metadata:
|
||||
name: nwmap1
|
||||
namespace: migration-system
|
||||
spec:
|
||||
networks:
|
||||
- source: VM Network
|
||||
target: vlan3002
|
||||
- source: VM Network 2
|
||||
target: vlan3003
|
||||
```
|
||||
## Datastore mapping
|
||||
```yaml
|
||||
apiVersion: vjailbreak.k8s.pf9.io/v1alpha1
|
||||
kind: StorageMapping
|
||||
metadata:
|
||||
name: stmap1
|
||||
namespace: migration-system
|
||||
spec:
|
||||
storages:
|
||||
- source: vcenter-datastore-1
|
||||
target: lvm
|
||||
- source: vcenter-datastore-2
|
||||
target: ceph
|
||||
```
|
||||
## VMwareMachine
|
||||
- `VMwareMachine` represents a discovered VMware VM and is created automatically by vJailbreak when a `VMwareCreds` resource is reconciled; it is not created by hand. `spec.vms` is a read-only snapshot of the VM's properties in vCenter (name, CPU, memory, datastores, networks, etc.) used to populate other resources such as `StorageMapping` and `NetworkMapping`.
|
||||
```yaml
|
||||
apiVersion: vjailbreak.k8s.pf9.io/v1alpha1
|
||||
kind: VMwareMachine
|
||||
metadata:
|
||||
name: vm-1
|
||||
namespace: migration-system
|
||||
spec:
|
||||
vms:
|
||||
name: vm-1
|
||||
cpu: 4
|
||||
memory: 8192
|
||||
osFamily: linuxGuest
|
||||
datastores:
|
||||
- datastore-1
|
||||
networks:
|
||||
- network-1
|
||||
targetFlavorId: "" # optional
|
||||
```
|
||||
- `targetFlavorId`: Optional. The OpenStack flavor ID to use for this VM's target VM. Set this to explicitly pin the migration to a specific flavor instead of relying on vJailbreak's automatic best-match selection (matched only on vCPU/RAM, so it cannot distinguish between same-sized flavors with different tags or extra specs). Must be set before the corresponding `MigrationPlan` is created, since it is read once when the per-VM migration ConfigMap is generated. If left empty, vJailbreak selects the closest matching flavor based on `spec.vms.cpu` and `spec.vms.memory`.
|
||||
|
||||
## MigrationTemplate
|
||||
```yaml
|
||||
apiVersion: vjailbreak.k8s.pf9.io/v1alpha1
|
||||
kind: MigrationTemplate
|
||||
metadata:
|
||||
name: migrationtemplate-windows
|
||||
namespace: migration-system
|
||||
spec:
|
||||
networkMapping: name_of_networkMapping
|
||||
storageMapping: name_of_storageMapping
|
||||
osFamily: windowsGuest/linuxGuest <optional>
|
||||
source:
|
||||
datacenter: name_of_datacenter
|
||||
vmwareRef: name_of_VMwareCreds
|
||||
destination:
|
||||
openstackRef: name_of_OpenstackCreds
|
||||
|
||||
```
|
||||
- `osFamily` is optional. If not provided, the `osFamily` is retrieved from vCenter. If it can't be automatically determined, migration will not proceed.
|
||||
## MigrationBlueprint
|
||||
A `MigrationBlueprint` is a saved, reusable migration configuration — what the UI calls a **Migration Template**. See [Migration Templates](../../guides/how-to/migration_templates/) for the workflow.
|
||||
|
||||
It is not the same object as the `MigrationTemplate` above. A `MigrationTemplate` is created per migration and drives an actual migration; a `MigrationBlueprint` is only read by the UI to pre-fill the migration form. The migration controller never reads it, and it holds no status.
|
||||
|
||||
```yaml
|
||||
apiVersion: vjailbreak.k8s.pf9.io/v1alpha1
|
||||
kind: MigrationBlueprint
|
||||
metadata:
|
||||
name: production-rhel-east
|
||||
namespace: migration-system
|
||||
spec:
|
||||
displayName: Production RHEL · East
|
||||
description: Cold copy into the east cluster <optional>
|
||||
vmwareRef: name_of_VMwareCreds
|
||||
vmwareClusterName: name_of_source_cluster
|
||||
pcdRef: name_of_OpenstackCreds
|
||||
targetPCDClusterName: name_of_target_PCD_cluster
|
||||
networkMappings:
|
||||
- source: VM Network
|
||||
target: external-network
|
||||
storageMappings:
|
||||
- source: vmware-datastore
|
||||
target: ceph
|
||||
storageCopyMethod: normal
|
||||
osFamily: windowsGuest/linuxGuest <optional>
|
||||
migrationStrategy:
|
||||
type: hot/cold
|
||||
adminInitiatedCutOver: true/false
|
||||
advancedOptions:
|
||||
networkPersistence: true/false
|
||||
securityGroups:
|
||||
- default
|
||||
serverGroup: name_of_server_group
|
||||
```
|
||||
|
||||
- `displayName`: Required. The name shown in the Templates tab. The object's `metadata.name` is a sanitized form of it.
|
||||
- Every other field is optional, so a partially configured form can still be saved as a template.
|
||||
- `vmwareClusterName`, `targetPCDClusterName`: Cluster **names**, not IDs. The UI resolves them back to the form's cluster selections when the template is applied.
|
||||
- `networkMappings`, `storageMappings`, `arrayCredsMappings`: Inline copies of the mapping pairs, not references to `NetworkMapping` or `StorageMapping` objects. This keeps a template intact when those per-migration objects are deleted.
|
||||
- `storageCopyMethod`: One of `normal`, `vJailbreakAcceleratedCopy`, or `StorageAcceleratedCopy`. Defaults to `normal`. `proxyVMRef` applies to `vJailbreakAcceleratedCopy`; `arrayCredsMappings` applies to `StorageAcceleratedCopy`.
|
||||
- The VM selection is deliberately absent — VMs are chosen each time the template is used.
|
||||
|
||||
## MigrationPlan
|
||||
```yaml
|
||||
apiVersion: vjailbreak.k8s.pf9.io/v1alpha1
|
||||
kind: MigrationPlan
|
||||
metadata:
|
||||
name: vm-migration-app1
|
||||
namespace: migration-system
|
||||
spec:
|
||||
migrationTemplate: migrationtemplate-windows
|
||||
retry: true/false <optional>
|
||||
advancedOptions:
|
||||
granularVolumeTypes:
|
||||
- newvoltype1
|
||||
granularNetworks:
|
||||
- newnetworkname1
|
||||
- newnetworkname2
|
||||
granularPorts:
|
||||
- <port uuid 1>
|
||||
- <port uuid 2>
|
||||
migrationStrategy:
|
||||
type: hot/cold
|
||||
dataCopyStart: 2024-08-27T17:30:25.230Z
|
||||
vmCutoverStart: 2024-08-27T17:30:25.230Z
|
||||
vmCutoverEnd: 2024-08-28T17:30:25.230Z
|
||||
adminInitiatedCutOver: true/false
|
||||
performHealthChecks: true/false
|
||||
healthCheckPort: string
|
||||
virtualMachines:
|
||||
- - winserver2k12
|
||||
- winserver2k16
|
||||
- - winserver2k19
|
||||
- winserver2k22
|
||||
```
|
||||
- `retry`: Optional. Retries one failed migration in a migration plan once. Set to false after a migration has been retried.
|
||||
- `advancedOptions`: This is an optional field for granular control over migration options. MigrationTemplate with mappings must still be present. These options override the ones in the template, if set. If you use these options, you must only have 1 VM present in the virtualMachines list.
|
||||
- `granularVolumeTypes`: In case you wish to provide different volume types to disks of a VM when they are all on the same datastore, you can specify the volume type of each disk of your VM in order. You must define one volume type for one disk present on the VM
|
||||
- `granularNetworks`: In case you wish to override the default network mapping for a VM, you can provide a list of OpenStack network names to use in for each NIC on the VM, in order.
|
||||
- `granularPorts`: In case you wish to pre-create ports for a VM with certain configs and directly provide them to the target VM, you can define a list of port IDS to be used for each network on the VM. It will override options set in `granularNetworks`.
|
||||
- `migrationStrategy`: This is an optional field
|
||||
- `type`:
|
||||
- `cold`: Cold indicates to power off VMs in migrationplan at the start of the migration. Quicker than hot.
|
||||
- `hot`: Powers VM off just before cutover starts. Data copy occurs with the source VM powered on. May take longer.
|
||||
- `dataCopyStart`: Optional. ISO 8601 timestamp indicating when to start data copy
|
||||
- `vmCutoverStart`: Optional. ISO 8601 timestamp indicating when to start VM cutover
|
||||
- `vmCutoverEnd`: Optional. ISO 8601 timestamp indicating the latest time by when VM cutover can start. If this time has been passed before the cutover can start, migration will fail.
|
||||
- `adminInitiatedCutOver`: Set to true if you wish to manually trigger the cutover process. Default: `false`
|
||||
- `performHealthChecks`: Set to false if you want to disable Ping and HTTP GET health check. Failing these checks does not clean up the targeted VM. Default: `false`
|
||||
- `healthCheckPort`: Port to run the HTTP GET health check against. Default "443"
|
||||
- `virtualmachines`: Specify names of VMs to migrate. In this example the batch of VMs `winserver2k12` and `winserver2k16` migrate in parallel. `winserver2k19` and `winserver2k22` will wait for the first 2 to complete successfully, and then start in parallel. You can use this notation to specify whether VMs should migrate sequentially or in parallel within a plan.
|
||||
|
||||
## VjailbreakNode
|
||||
vJailbreak can be scaled to perform multiple migrations in parallel by deploying additional `agents`, enabling greater efficiency and workload distribution. The VjailbreakNode Custom Resource Definition (CRD) streamlines the creation and management of these agents, ensuring seamless integration into the migration workflow. Each `VjailbreakNode` represents a VM that functions as an independent migration `agent`. These agents are dynamically added to the original `VjailbreakNode`, forming a cohesive cluster that enhances scalability, reliability, and overall migration performance.
|
||||
```yaml
|
||||
apiVersion: vjailbreak.k8s.pf9.io/v1alpha1
|
||||
kind: VjailbreakNode
|
||||
metadata:
|
||||
name: example-vjailbreak-node
|
||||
namespace: migration-system
|
||||
spec:
|
||||
imageId: "your-openstack-image-id" # This ID is for the first vjailbreak VMimage. It auto-populates in the UI—do not delete it.
|
||||
nodeRole: "worker"
|
||||
openstackCreds:
|
||||
name: "name" # Reference to your OpenstackCreds
|
||||
namespace: "migration-system"
|
||||
openstackFlavorId: "your-openstack-flavor-id"
|
||||
```
|
||||
This `VjailbreakNode` CRD defines a Kubernetes resource that provisions a VM in OpenStack to act as a migration agent. Below is a breakdown of each field:
|
||||
- `metadata:` Metadata contains identifying details about the `VjailbreakNode`.
|
||||
- `name: example-vjailbreak-node`: Specifies the name of this `VjailbreakNode` resource in Kubernetes.
|
||||
- `namespace: migration-system`: Indicates the namespace where this resource is deployed within the Kubernetes cluster.
|
||||
|
||||
The `spec` section defines the desired state of the `VjailbreakNode`.
|
||||
|
||||
- `imageId: "your-openstack-image-id"`: This is the ID of the OpenStack image used to create the VM.
|
||||
- **It must match the image ID used to create the initial vJailbreak VM**, ensuring compatibility across all migration agents.
|
||||
- `nodeRole: "worker"`: Defines the role of the node.
|
||||
- It should be set to `"worker"` as this node functions as a migration agent within the vJailbreak cluster.
|
||||
- `openstackCreds:`: OpenstackCreds use the variables from the openstack.rc file.
|
||||
- `name: "name"` → Refers to a `Secret` or `CustomResource` storing OpenStack authentication details.
|
||||
- `namespace: "migration-system"` → The namespace where OpenStack credentials are stored.
|
||||
- `openstackFlavorId: "your-openstack-flavor-id"`: Specifies the OpenStack flavor ID, which determines the VM's compute resources (CPU, RAM, disk size, etc.).
|
||||
- The chosen flavor should align with the resource requirements for migration workloads.
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: v0.4.10
|
||||
description: Release Notes for v0.4.10
|
||||
---
|
||||
|
||||
## What's Changed
|
||||
* Enabling other copy methods without vddk- #2350 by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2353
|
||||
* Adding directory or create by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2356
|
||||
* [2358] Add VDDK_REQUIRED configmap flag to gate mandatory VDDK upload redirect by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2359
|
||||
* [2363] Default migration form to vJailbreak Accelerated Copy (HotAdd) by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2362
|
||||
* Pre-release CRD generation for v0.4.10 by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2370
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.4.9...v0.4.10
|
||||
|
||||
## Highlights
|
||||
This is a quick release in response to VDDK unavailability. More details - https://platform9.com/blog/vddk-no-longer-available/
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: v0.4.6
|
||||
description: Release Notes for v0.4.6
|
||||
---
|
||||
|
||||
## What's Changed
|
||||
* [1822] Removed redundant field (AssignedIP) by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1899
|
||||
* [1907] Fix: fetch single VMwareMachine instead of entire list in migration detail query by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1903
|
||||
* [1241] Disable port security on migrated ports when no security group is selected while migration by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1892
|
||||
* #1822: Display All VM IP Addresses in Migration Details Page (Assigned & Preserved IPs) by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1911
|
||||
* [1897] Feat: Add controller logs button to topbar in UI by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1896
|
||||
* docs(CLAUDE.md): add unit test requirements for Claude-written code by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1917
|
||||
* [1830] Fix: Include RBAC-shared security groups in destination tenant security group list by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1910
|
||||
* [1925] ci: Shift nightly build trigger to 01:00 IST by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1924
|
||||
* [1920] Added warnings for selected VMs with missing IPs by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1918
|
||||
* [1913] Fix: Skip VMwareMachine reconciliation for migrated VMs by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1912
|
||||
* #973: Verify vCenter FQDN DNS resolution by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1928
|
||||
* [1931] feat: Add debug bundle collection with resources and logs for easier troubleshooting by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1929
|
||||
* Bug: Filter Flavor Selection on AZ and flavours without AZ by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1916
|
||||
* [1840] Added the ability to migrate the VMs with no interface by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1927
|
||||
* Updating the compute api version to support multi-attach volumes by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1932
|
||||
* [1921] feat: Show revalidation progress on Credentials page by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1919
|
||||
* [1890] agent dns config by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1937
|
||||
* [1888] refactor: Remove direct pod permissions by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1935
|
||||
* [1938] Support VMs with space in their name by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1936
|
||||
* [1933] Don't restart ui when listing users by @spai-p9 in https://github.com/platform9/vjailbreak/pull/1939
|
||||
* [1796] Optimising the copy changed blocks mechanism for faster sync by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1934
|
||||
* #587: UI refactor migration by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1960
|
||||
* #1940: Block v2v pod creation or disable start migration if vddk is not uploaded by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1969
|
||||
* #1873: Block security group selection during scaling L2 Agent by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1962
|
||||
* [1803] fix: Added retry for transient API errors by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1958
|
||||
* [1961] fix: Handle transient vCenter errors during VM power-off by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1973
|
||||
* [1610] Fix VMware Tools cleanup for Linux/SUSE VMs by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1968
|
||||
* [1482] Adding hot add proxy by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1964
|
||||
* [1978] Sles LVM Minitrd fix by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/1976
|
||||
* #1971: UI hot add proxy migration complete UI requirements by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1981
|
||||
* UI E2E testcases with mock data using playwright by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/1972
|
||||
* Fix cluster conversion issues by @geet-pf9 in https://github.com/platform9/vjailbreak/pull/1984
|
||||
* [1990] Fix boot device index parse failure due to mixed guestfish stderr/stdout by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1993
|
||||
* Hypervisor resmgr role Cluster Conversion by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1997
|
||||
* #1999: Security group warning should be visible for Use security group of primary vJB vm by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/2000
|
||||
* [2004] Fix SLED OS detection and broaden SSH key format support by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2003
|
||||
* [2002] fix- Cant upload key Invalid key error for RSA key by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/2006
|
||||
* [2009] Unified logs icons and aligned migration name across logs drawer and details by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2008
|
||||
* Update CRD for v0.4.6 by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2017
|
||||
|
||||
|
||||
## Highlights
|
||||
**Hot Add Proxy**: Hot-Add Proxy is an advanced data copy method that attaches source VM disks directly to a dedicated Proxy VM and streams the data over NBD (Network Block Device) to the destination. Instead of copying data over the NFC protocol from ESXi. This feature is currently in beta, will be stabilized in the coming releases.
|
||||
|
||||
**Migration Reliability**:
|
||||
- VMs with no network interfaces can now be migrated successfully.
|
||||
- Multi-attach volume types are now supported for migration.
|
||||
|
||||
**Enhanced UX**:
|
||||
- All IP addresses (assigned and preserved) are now shown on the Migration Details page in the UI.
|
||||
- Controller logs (migration controller manager) are visible in the UI irrespective of any migrations triggered.
|
||||
- A debug bundle collection button makes log and resource gathering easier for troubleshooting. All CRs related to that migration are now gathered for easier debugging.
|
||||
|
||||
|
||||
## Known Limitations
|
||||
- Migrations of VMs with grub version lower than 2 might face issues while booting post migration.
|
||||
|
||||
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.4.5...v0.4.6
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: v0.4.7
|
||||
description: Release Notes for v0.4.7
|
||||
---
|
||||
|
||||
## What's Changed
|
||||
* Fixed the missing --binding-profile '{"l2-port": true}' on ports created for VMs migrated onto L2-only networks in PCD by @spai-p9 in https://github.com/platform9/vjailbreak/pull/2015
|
||||
* [2007] Fix fstab rewrite incorrectly activating commented bind-mount entries by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2011
|
||||
* [1058] Configure NTP servers and system timezone for the vJailbreak VM directly from the UI by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/1742
|
||||
* [1915] Added persist source network interfaces as a global setting by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2025
|
||||
* Detect if we are using virtio-scsi controller for windows and pass --blockdriver for conversion by @spai-p9 in https://github.com/platform9/vjailbreak/pull/2027
|
||||
* [1812] Fix volume cleanup when CreateTargetInstance times out by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2026
|
||||
* [1975] Hot-Add Proxy VM UX improvements by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2023
|
||||
* [1996] upgrade core components with guest OS migration fixes by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2031
|
||||
* [1970] Add server group selection for agent scale-up to control placement affinity by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2032
|
||||
* [1979] VM selection refresh button now revalidates VMware credentials by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2034
|
||||
* [1872] Verify volume bootable state after SetBootable timeout by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2035
|
||||
* prebake proxy VM OVA into appliance image by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2038
|
||||
* Fix: Check hardware version and migration type only then check for cbt by @spai-p9 in https://github.com/platform9/vjailbreak/pull/2037
|
||||
* [1980] Enhance user experience with new UI by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/2040
|
||||
* UI side changes for Hot add proxy improvements by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2030
|
||||
* Rename Firstboot-Scheduler.ps1 to 0-Firstboot-Scheduler.ps1 by @noaboa97 in https://github.com/platform9/vjailbreak/pull/1994
|
||||
* fix(v2v-helper): repair broken build on main by @valentin-pf9 in https://github.com/platform9/vjailbreak/pull/1945
|
||||
* [1750] UI for edit and retry by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2024
|
||||
* [2044] Consolidate edit-and-retry into single Retry action by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2021
|
||||
* #2047 : Need UI enhancement in hot add proxy changes by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/2048
|
||||
* [2050] Optimize retry flow and add bulk retry by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2049
|
||||
* [2052] Fix Windows firstboot loop by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2056
|
||||
* [1915] Added persist source network interfaces as a global setting by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2058
|
||||
* [2054] fix(retry): prefilled IP overrides not shown in Assign IP dialog on retry form by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2059
|
||||
* [2062] fix - ssh keypair name missmatch by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2060
|
||||
* #2051: Converting disk shows copy disk inside the migration details page by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/2063
|
||||
* #2067: Block/Grey out the already registered proxy vm, this could mismatch the secret by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/2070
|
||||
* [2079] Fix ProxyVM showing Ready status while SSH validation is failing by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2080
|
||||
* #2068 #2078 #2069: VM is in conversion state but it shows Hot add transfer in UI and stuck in validating state by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/2074
|
||||
* [2077] Fix: Reset to Defaults must skip NTP server & timezone while migration running by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2084
|
||||
* #2088: [UI] Windows VM should be blocked for selection as a proxy VM by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/2089
|
||||
* [2093] feat: add debug-bundle API to vpwned by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2090
|
||||
* #2082: Debug logs, yamls are not present in logs fetched using log download button by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/2092
|
||||
* Fix Host Entries tab: duplicate description text and low-visibility button by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2099
|
||||
|
||||
## New Contributors
|
||||
* @noaboa97 made their first contribution in https://github.com/platform9/vjailbreak/pull/1994
|
||||
* @valentin-pf9 made their first contribution in https://github.com/platform9/vjailbreak/pull/1945
|
||||
|
||||
## Highlights
|
||||
**Migration details page**: Added new page which shows in depth state monitoring for migration lifecycle.
|
||||
|
||||
**Vjailbreak Proxy**:
|
||||
* End-to-end UI for registering a Proxy VM (SSH key upload, validation status), selecting Hot-Add as the copy method in the migration form, and monitoring hot-add-specific migration phases
|
||||
* Verification now auto-installs missing dependencies on the Proxy VM during validation, eliminating the need for manual pre-configuration before registering
|
||||
|
||||
**Advanced Configuration Management**
|
||||
* Configure **NTP servers** and **system timezone** for vJailbreak VMs directly from the UI.
|
||||
* Introduced **server group selection** for agent scale-up, enabling better placement and affinity control.
|
||||
|
||||
**Enhanced Retry Experience**
|
||||
* Introduced a new Edit & Retry capability, allowing users to modify migration settings and retry failed migrations without recreating the migration.
|
||||
* Simplified recovery with a unified Retry action and support for Bulk Retry, reducing manual effort.
|
||||
|
||||
|
||||
## Known Limitations
|
||||
|
||||
**Proxy VM OVA requires ESXi 8.0 U2 or higher**: The bundled OVA template uses virtual hardware version vmx-21, which is incompatible with older ESXi hosts. Attempting to deploy it on ESXi 7.x will fail with an "unsupported hardware family" error. For ESXi 7.x environments, the Proxy VM must be created and configured manually instead of using the OVA deploy option.
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.4.6...v0.4.7
|
||||
@@ -0,0 +1,85 @@
|
||||
---
|
||||
title: v0.4.8
|
||||
description: Release Notes for v0.4.8
|
||||
---
|
||||
|
||||
## What's Changed
|
||||
* #2067: Block/Grey out the already registered proxy vm, this could mismatch the secret by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/2105
|
||||
* [2083] Infer hotplug intent from assigned flavor by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2109
|
||||
* fix: security workflow fork PR comments + graphify git noise by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/2116
|
||||
* test(v2v-helper): repair stale mkinitrd LVM wrapper unit tests by @gtherond in https://github.com/platform9/vjailbreak/pull/2075
|
||||
* [2106] Fix wrong stage shown for Hot-Add proxy migrations by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2117
|
||||
* [2085] Block Persist source network interfaces when mapped network subnet doesn't match VM IPs by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2110
|
||||
* [2095] Serve debug bundle as .tar.gz archive instead of single .txt file by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2112
|
||||
* [2113] Improved subnet mismatch warning and Persist IP disabled warning by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2126
|
||||
* refactor: remove deprecated files and components, streamline package dependencies by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/2114
|
||||
* Don't call openstackcreds per cluster to get tenant name by @spai-p9 in https://github.com/platform9/vjailbreak/pull/2057
|
||||
* #2087 : Add confirmation dialog for node reprovisioning by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/2131
|
||||
* #2094: [UI] Update Controller Log Section Styling to Match Migration Details Logs by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/2136
|
||||
* [2128] Show assigned flavor and disk size for VMs selected for migration by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2137
|
||||
* [1930] Fix CentOS 7 conversion failure from e2fsck bitmap errors by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2134
|
||||
* Delete associated agent nodes when OpenstackCreds is deleted by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/2119
|
||||
* #2125: Move Proxy VM Credentials Navigation from Credentials to Migration Menu by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/2138
|
||||
* Refactor: ReservePortsForVM by @spai-p9 in https://github.com/platform9/vjailbreak/pull/2140
|
||||
* [2012] Fix SUSE GRUB Legacy device references post-migration by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2133
|
||||
* AI analysis of migration failures by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/1998
|
||||
* [1801] Twice HOTPLUG_CPU_MAX/HOTPLUG_MEMORY_MAX metadata so migrated VMs can be resized on PCD by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2127
|
||||
* [2167] fix(v2v-helper): Install vendored libnbd with libnbd-devel by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2166
|
||||
* When Ip is empty and fallback to dhcp true ask pcd to assign ip via dhcp by @spai-p9 in https://github.com/platform9/vjailbreak/pull/2153
|
||||
* [2161] fix(ui): Global Settings Save button silently dead by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2162
|
||||
* [428] Added ability to preserve tags, attributes, and custom metadata attached to the virtual machine by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2146
|
||||
* [2115] Fix IP address not populating on port creation due to MAC address case mismatch by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2160
|
||||
* [428] UI: Added ability to preserve tags, attributes, and custom metadata attached to the virtual machine by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2145
|
||||
* [2096] Default removeVMwareTools to true by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/2159
|
||||
* Make clean up both agents and vjb nodes to run as background and improve reliability by @spai-p9 in https://github.com/platform9/vjailbreak/pull/2155
|
||||
* Refactoring boot partition detection by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2168
|
||||
* Separate out nbd and virtv2v debug logs by @spai-p9 in https://github.com/platform9/vjailbreak/pull/2165
|
||||
https://github.com/platform9/vjailbreak/pull/2172
|
||||
* [2173] Remove beta tag from Storage Accelerated Copy by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2177
|
||||
* [2152] Add MigrationBlueprint CRD to support migration templates by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2158
|
||||
* [2175] UI patch call for proxy vm retry by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2181
|
||||
* [2176] Fix tags toggle needing two clicks to enable by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2183
|
||||
* [2184] Fix Migration Options toggles needing two clicks to enable by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2185
|
||||
* #2120: Add Support for Migration Templates and Saved Configurations by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/2180
|
||||
* Configure guest network incase of ubuntu for fallback to dhcp case by @spai-p9 in https://github.com/platform9/vjailbreak/pull/2182
|
||||
* [2178] fix(migration): disable persist network interfaces when Preserve IP is off and mapped to diff network by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2189
|
||||
* Feature: Add error propogation to UI from debug logs for failures by @spai-p9 in https://github.com/platform9/vjailbreak/pull/2170
|
||||
* [2213] Fix migration stuck in ConvertingDisk after transient VM creation timeout by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/2192
|
||||
* [2143] unique port names for multi-NIC VMs using network+subnet+vmname by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/2147
|
||||
* [2191] Grid/list toggle wraps left instead of staying inline on Templates tooolbar by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2199
|
||||
* [2193] Prevent checkbox selection column from being hidden via Manage Columns by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2198
|
||||
* [2194] Fix: Converting Disk status should not show count of disks by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2200
|
||||
* [2202] Fix: AI Analysis key configuration redirect to correct settings tab by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2204
|
||||
* feat: add data-only migration mode (no VM creation) (#492) by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/2171
|
||||
* Support encrypted volume types in pcd. by @spai-p9 in https://github.com/platform9/vjailbreak/pull/2208
|
||||
* [2201] Show migration failure messages on the UI by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2205
|
||||
* [2203] Fix: Disable migration progress bar by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2210
|
||||
* #2209: Step check marks doesnt disable if user disable the option by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/2215
|
||||
* [2214] Fix: Controller/pod log search returns zero results for lines that exist by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2221
|
||||
* [2217] Fix: Remove stale network/storage mappings when VMs are deselected by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2222
|
||||
* feat(dev): add Claude Code agent definitions for vjailbreak workflows by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/2223
|
||||
* [2195] Fix incorrect step timings on the migration detail page by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2225
|
||||
* [2213] Fix: Migration phase permanently frozen at Failed from transient kubelet events by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2229
|
||||
* [2234] Fix: remove VM selection from template creation and refactor pruning of mappings by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2233
|
||||
* [CI] modify pre-release actions to not skip builds by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/2239
|
||||
|
||||
## New Contributors
|
||||
* @gtherond made their first contribution in https://github.com/platform9/vjailbreak/pull/2075
|
||||
|
||||
## Highlights
|
||||
|
||||
* Introduced log analysis for failed migrations using Anthropic AI to help identify potential root causes and simplify troubleshooting.
|
||||
* Added ability to preserve source vCenter VM tags, attributes, and custom metadata during migration.
|
||||
* Promoted Storage Assisted Migration to General Availability (GA).
|
||||
* Added support for Migration Templates and Saved Configurations to streamline repeated migration workflows.
|
||||
* Added support for Data-Only migration mode, enabling data transfer without creating the destination VM.
|
||||
* Added support for migrating KMS-encrypted source VMs.
|
||||
|
||||
## Known Limitations
|
||||
|
||||
* The **Data-Only** migration option is not preserved when a migration is retried using the **Retry** button. See [[Issue #2245](https://github.com/platform9/vjailbreak/issues/2245)] for details.
|
||||
* Migrations of VMs running **RHEL 7.9** may intermittently encounter a disk index-related issue. Retrying the migration typically resolves the problem.
|
||||
* When using the **Hotplug** flavor for migration, the destination VM's **Maximum CPU** and **Maximum Memory** values are set to twice the original VM's configured CPU and memory in vCenter.
|
||||
* Migration of **SUSE Linux Enterprise Server (SLES)** and **SUSE Linux Enterprise Desktop (SLED)** systems using **Legacy GRUB 0.97** is not supported.
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.4.7...v0.4.8
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: v0.4.9
|
||||
description: Release Notes for v0.4.9
|
||||
---
|
||||
|
||||
## What's Changed
|
||||
* improve vjb debug skill and add security review skill by @OmkarDeshpande7 in https://github.com/platform9/vjailbreak/pull/2230
|
||||
* [2247] Fix: 403 Forbidden fetching migration ConfigMap on migration details page by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2253
|
||||
* [2179] fix(migration): recompute subnet-mismatch warning when IP changes after network mapping by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2190
|
||||
* #2211: UI: Filter not working by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/2267
|
||||
* [2270] fix: report failed vmkfstools clones as failures by @spai-p9 in https://github.com/platform9/vjailbreak/pull/2272
|
||||
* [2245] Fix: Persist data-only, source tags and custom metadata when retrying a failed migration by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2264
|
||||
* [2246] Show data-only mode in migration details page policies by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2275
|
||||
* [2262] Warn before upgrade cleanup and gate Upgrade on cleanup by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2276
|
||||
* [2257] Fix migration failure when the guest root filesystem spans multiple disks by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2232
|
||||
* [2283] [Claude] Constitution v1.3.0 — migration form field parity + explicit UI K8s access by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2281
|
||||
* [2228] Cannot create cred with same name if previous attempt failed by @AbhijeetThakur in https://github.com/platform9/vjailbreak/pull/2249
|
||||
* [2279] fix(upgrade): server-side apply manifests so bound PVCs don't fail the CRD phase by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2284
|
||||
* [2278] Adding ability to migrate LDM VMs by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2277
|
||||
* [2286] Added vjailbreak-ai to the upgrade flow by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2285
|
||||
* [2289] LDM UI popup renaming by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2291
|
||||
* [2296] fix win2k12 troubleshooting mode by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2297
|
||||
* [2287] Adding extra phase for transition from sata to virtio by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2293
|
||||
* [2290] Adding disk detach path on keep sata option by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2295
|
||||
* [2288] marking success on keep sata path by @meghansh-pf9 in https://github.com/platform9/vjailbreak/pull/2294
|
||||
* [2279] fix(upgrade): keep the AI PVC out of 00crds.yaml by @sarika-pf9 in https://github.com/platform9/vjailbreak/pull/2299
|
||||
|
||||
## Highlights
|
||||
|
||||
* Added support for Windows VMs with LDM system disk
|
||||
* UI Retry related stability fixes
|
||||
* Added support for Linux VMs with BTRFS
|
||||
|
||||
## Known Limitations
|
||||
|
||||
* Race condition with vjailbreak accelerated proxy - #2300
|
||||
* Multi-IP assignment limitation - #2163
|
||||
* Incorrect migration copy progress on UI - #2139
|
||||
|
||||
**Full Changelog**: https://github.com/platform9/vjailbreak/compare/v0.4.8...v0.4.9
|
||||
@@ -0,0 +1,454 @@
|
||||
/* Override default card grid layout */
|
||||
.card-grid {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
|
||||
gap: 1.5rem;
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
/* Make all cards the same height */
|
||||
.card {
|
||||
height: 100%;
|
||||
margin: 0 !important;
|
||||
transform: none !important;
|
||||
}
|
||||
|
||||
/* Remove stagger animation */
|
||||
.card-grid[data-stagger] .card {
|
||||
animation: none !important;
|
||||
}
|
||||
|
||||
/* Import Geist font */
|
||||
@font-face {
|
||||
font-family: 'Geist';
|
||||
src: url('https://assets.website-files.com/638d2ca7e839e538fc311594/638d2ca7e839e54527311772_Geist-Regular.woff2') format('woff2'),
|
||||
url('https://assets.website-files.com/638d2ca7e839e538fc311594/638d2ca7e839e54527311772_Geist-Regular.woff') format('woff');
|
||||
font-weight: 400;
|
||||
font-style: normal;
|
||||
}
|
||||
|
||||
@font-face {
|
||||
font-family: 'Geist';
|
||||
src: url('https://assets.website-files.com/638d2ca7e839e538fc311594/638d2ca7e839e54527311773_Geist-Medium.woff2') format('woff2'),
|
||||
url('https://assets.website-files.com/638d2ca7e839e538fc311594/638d2ca7e839e54527311773_Geist-Medium.woff') format('woff');
|
||||
font-weight: 500;
|
||||
font-style: normal;
|
||||
}
|
||||
|
||||
/* Override Starlight's default fonts */
|
||||
:root {
|
||||
--sl-font: 'Geist', -apple-system, BlinkMacSystemFont, sans-serif;
|
||||
}
|
||||
|
||||
@media (min-width: 1600px) {
|
||||
:root {
|
||||
--sl-content-width: 80rem;
|
||||
}
|
||||
}
|
||||
|
||||
/* Specific element styling */
|
||||
h1, h2, h3, h4, h5, h6 {
|
||||
font-family: var(--sl-font);
|
||||
font-weight: 500;
|
||||
}
|
||||
|
||||
.hero-image {
|
||||
width: 100%; /* This will make the image take the full width of its container */
|
||||
height: auto; /* Maintain aspect ratio */
|
||||
max-width: 1400px; /* Optional: to limit the image width to a max */
|
||||
margin: 0 auto; /* Centers the image */
|
||||
}
|
||||
|
||||
.hero-image.large {
|
||||
max-width: 1600px; /* Increase the maximum size for larger screens */
|
||||
}
|
||||
|
||||
.hero h1 {
|
||||
font-weight: 500;
|
||||
letter-spacing: -0.02em;
|
||||
}
|
||||
|
||||
p, li {
|
||||
font-family: var(--sl-font);
|
||||
font-weight: 400;
|
||||
}
|
||||
|
||||
/* Platform9 theme colors */
|
||||
:root {
|
||||
--p9-blue: #0091ff; /* Primary blue */
|
||||
--p9-dark-blue: #0d1b2a; /* Darker blue for backgrounds */
|
||||
--p9-light-blue: #61a0ff; /* Light blue for accents */
|
||||
}
|
||||
|
||||
|
||||
@keyframes shimmer {
|
||||
0% { background-position: -200% center; }
|
||||
100% { background-position: 200% center; }
|
||||
}
|
||||
|
||||
/* Enhanced video container */
|
||||
.video-container {
|
||||
position: relative;
|
||||
z-index: 2; /* Higher than overlay */
|
||||
pointer-events: auto; /* Ensure clicks pass through */
|
||||
}
|
||||
|
||||
.video-wrapper {
|
||||
position: relative;
|
||||
border-radius: 12px;
|
||||
box-shadow: 0 12px 32px rgba(0, 0, 0, 0.15);
|
||||
border: 1px solid rgba(97, 160, 255, 0.1);
|
||||
overflow: hidden;
|
||||
transform: translateY(0);
|
||||
transition: transform 0.3s ease, box-shadow 0.3s ease;
|
||||
}
|
||||
|
||||
.video-wrapper iframe {
|
||||
position: relative;
|
||||
z-index: 3; /* Highest z-index */
|
||||
width: 100%;
|
||||
height: calc(100% - (10px)); /* Adjust height for padding if needed */
|
||||
border-radius :12px; /* Add border-radius to iframe for consistency with wrapper*/
|
||||
border : none; /* Remove default border on iframe*/
|
||||
}
|
||||
|
||||
/* Enhanced action buttons */
|
||||
[data-has-hero] .action {
|
||||
transition: transform 0.2s ease, box-shadow 0.2s ease;
|
||||
}
|
||||
|
||||
[data-has-hero] .action:hover {
|
||||
transform: translateY(-2px);
|
||||
}
|
||||
|
||||
[data-has-hero] .action.primary {
|
||||
background-image : linear-gradient(135deg, var(--p9-blue), var(--p9-light-blue));
|
||||
border-radius :8px; /* Add rounded corners to buttons*/
|
||||
}
|
||||
|
||||
[data-has-hero] .action.minimal {
|
||||
border-color : var(--p9-blue);
|
||||
}
|
||||
|
||||
/* CSS for sections in index page */
|
||||
/* Section styling */
|
||||
.section-title {
|
||||
color : var(--sl-color-white);
|
||||
font-size :2rem ;
|
||||
margin :3rem auto ; /* Center the title with auto margins*/
|
||||
background-image : linear-gradient(
|
||||
to right,
|
||||
var(--sl-color-text) ,
|
||||
var(--p9-blue) ,
|
||||
var(--sl-color-text)
|
||||
);
|
||||
-webkit-background-clip : text ;
|
||||
background-clip : text ;
|
||||
-webkit-text-fill-color : transparent ;
|
||||
}
|
||||
|
||||
/* Card styling */
|
||||
.card-grid[data-theme='light'] .card {
|
||||
background-image : linear-gradient(
|
||||
to bottom right,
|
||||
rgba(255,255,255,.9),
|
||||
rgba(240,245,250,.8)
|
||||
);
|
||||
border :1px solid rgba(0,145,255,.1);
|
||||
}
|
||||
|
||||
.card-grid[data-theme='dark'] .card {
|
||||
background-image : linear-gradient(
|
||||
to bottom right,
|
||||
rgba(13,27,42,.9),
|
||||
rgba(27,38,59,.8)
|
||||
);
|
||||
border :1px solid rgba(0,145,255,.2);
|
||||
}
|
||||
|
||||
.card {
|
||||
transition :transform .2s ease ,box-shadow .2s ease ;
|
||||
box-shadow :0px4px16px rgba(0 ,145 ,255 , .1);
|
||||
}
|
||||
|
||||
.card:hover {
|
||||
transform :translateY(-4px);
|
||||
box-shadow :0px8px24px rgba(0 ,145 ,255 , .15);
|
||||
}
|
||||
|
||||
|
||||
/* CSS for download button */
|
||||
.download-section {
|
||||
margin :2rem auto ;
|
||||
padding :1.5rem ;
|
||||
background-image : linear-gradient(
|
||||
to bottom right,
|
||||
var(--sl-color-bg),
|
||||
var(--sl-color-bg-sidebar)
|
||||
);
|
||||
border-radius :12px ;
|
||||
border :1px solid rgba(0 ,145 ,255 , .1);
|
||||
}
|
||||
|
||||
.download-content {
|
||||
display :flex ;
|
||||
align-items:center ;
|
||||
gap :2rem ;
|
||||
max-width :var(--sl-content-width);
|
||||
margin :0 auto ;
|
||||
}
|
||||
|
||||
.download-section h3 {
|
||||
font-size :1.2rem ;
|
||||
margin :0 ;
|
||||
color :var(--sl-color-text);
|
||||
}
|
||||
|
||||
.command-box {
|
||||
position :relative ;
|
||||
flex-grow :1 ;
|
||||
margin :0 ;
|
||||
padding :.75rem ;
|
||||
background-color :var(--sl-color-bg-sidebar);
|
||||
border-radius :8px ;
|
||||
}
|
||||
|
||||
.command-box pre {
|
||||
margin :0 ;
|
||||
padding-right :4rem ; /* Make space for copy button */
|
||||
}
|
||||
|
||||
.copy-button {
|
||||
position: absolute;
|
||||
right: 0.75rem;
|
||||
top: 50%;
|
||||
transform: translateY(-50%);
|
||||
background: var(--sl-color-text-accent);
|
||||
color: white;
|
||||
border: none;
|
||||
border-radius: 4px;
|
||||
padding: 0.3rem;
|
||||
cursor: pointer;
|
||||
font-size: 1.2rem; /* Icon size */
|
||||
transition: all 0.2s ease;
|
||||
display: flex;
|
||||
justify-content: center;
|
||||
align-items: center; /* Aligns icon and text vertically */
|
||||
gap: 0.4rem; /* Adds space between the icon and the text */
|
||||
}
|
||||
|
||||
.copy-button svg {
|
||||
width: 1.2rem; /* Adjust icon size */
|
||||
height: 1.2rem;
|
||||
}
|
||||
|
||||
.copy-button:hover {
|
||||
background: var(--p9-light-blue);
|
||||
transform: translateY(-50%) scale(1.05);
|
||||
}
|
||||
|
||||
|
||||
.oras-link{
|
||||
font-size:.8rem ;
|
||||
color: var(--sl-color-text-accent);
|
||||
text-decoration:none ;
|
||||
display:flex ;
|
||||
align-items:center ;
|
||||
gap:.3rem ;
|
||||
white-space: nowrap ;
|
||||
}
|
||||
|
||||
.oras-link:hover{
|
||||
text-decoration: underline ;
|
||||
color: var(--p9-light-blue);
|
||||
}
|
||||
/* Modal Overlay */
|
||||
.modal-overlay {
|
||||
display: none;
|
||||
justify-content: center;
|
||||
align-items: center;
|
||||
position: fixed;
|
||||
top: 0;
|
||||
left: 0;
|
||||
width: 100%;
|
||||
height: 100%;
|
||||
background-color: rgba(0, 0, 0, 0.5);
|
||||
opacity: 0;
|
||||
transition: opacity 0.3s ease;
|
||||
}
|
||||
|
||||
/* Active State for Modal */
|
||||
.modal-overlay.active {
|
||||
display: flex;
|
||||
opacity: 1;
|
||||
}
|
||||
|
||||
/* Modal Container */
|
||||
.modal-container {
|
||||
/*background-color: #fff;*/
|
||||
border-radius: 12px;
|
||||
padding: 2rem;
|
||||
max-width: 500px;
|
||||
width: calc(100% - 2rem);
|
||||
position: fixed;
|
||||
top: 50%;
|
||||
left: 50%;
|
||||
transform: translate(-50%, -50%);
|
||||
background-color: white;
|
||||
padding: 20px;
|
||||
box-shadow: 0px 4px 6px rgba(0, 0, 0, 0.1);
|
||||
border-radius: 8px;
|
||||
z-index: 1000; /* Ensure it's on top of other elements */
|
||||
}
|
||||
|
||||
/* Modal Header */
|
||||
.modal-header {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
align-items: center;
|
||||
}
|
||||
|
||||
.modal-header h3 {
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
.modal-close {
|
||||
background: none;
|
||||
border: none;
|
||||
font-size: 1.5rem;
|
||||
cursor: pointer;
|
||||
}
|
||||
|
||||
/* Input and Submit Button */
|
||||
input {
|
||||
width: calc(100% - 2rem);
|
||||
padding: .75rem;
|
||||
}
|
||||
|
||||
button[type='submit'] {
|
||||
margin-top :1rem ;
|
||||
color:white ;
|
||||
background-image : linear-gradient(to bottom , var(--p9-blue),var(--p9-light-blue));
|
||||
}
|
||||
|
||||
/* .dropdown {
|
||||
position: relative;
|
||||
display: inline-block;
|
||||
}
|
||||
|
||||
.dropdown-button {
|
||||
background-color: #0077B6;
|
||||
color: white;
|
||||
padding: 10px 15px;
|
||||
border: none;
|
||||
cursor: pointer;
|
||||
}
|
||||
|
||||
.dropdown-menu {
|
||||
display: none;
|
||||
position: absolute;
|
||||
background-color: #f9f9f9;
|
||||
min-width: 160px;
|
||||
box-shadow: 0px 8px 16px rgba(0, 0, 0, 0.2);
|
||||
z-index: 1;
|
||||
}
|
||||
|
||||
.dropdown:hover .dropdown-menu {
|
||||
display: block;
|
||||
}
|
||||
|
||||
.dropdown-item {
|
||||
padding: 8px 12px;
|
||||
text-decoration: none;
|
||||
display: block;
|
||||
}
|
||||
|
||||
.dropdown-item:hover {
|
||||
background-color: #ddd;
|
||||
} */
|
||||
|
||||
.slack-invite {
|
||||
position: relative; /* Needed for absolute positioning of close button */
|
||||
}
|
||||
|
||||
.custom-icon-button {
|
||||
background: none;
|
||||
border: none;
|
||||
cursor: pointer;
|
||||
}
|
||||
|
||||
#custom-form {
|
||||
position: fixed;
|
||||
top: 50%;
|
||||
left: 50%;
|
||||
transform: translate(-50%, -50%);
|
||||
background-color: white;
|
||||
padding: 20px;
|
||||
box-shadow: 0px 4px 6px rgba(0, 0, 0, 0.1);
|
||||
border-radius: 8px;
|
||||
z-index: 1000; /* Ensure it's on top of other elements */
|
||||
}
|
||||
|
||||
.close-button {
|
||||
position: absolute;
|
||||
top: 10px;
|
||||
right: 10px;
|
||||
font-size: 20px;
|
||||
cursor: pointer;
|
||||
}
|
||||
|
||||
.rate-limit-warning {
|
||||
display: none;
|
||||
color: #dc3545;
|
||||
padding: 0.5rem;
|
||||
margin-top: 0.5rem;
|
||||
border: 1px solid #dc3545;
|
||||
border-radius: 4px;
|
||||
}
|
||||
|
||||
|
||||
.version-buttons {
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
gap: 0.5rem;
|
||||
margin-bottom: 1.5rem;
|
||||
}
|
||||
|
||||
.version-btn {
|
||||
padding: 0.5rem 1rem;
|
||||
font-size: inherit;
|
||||
line-height: 1.2;
|
||||
font-weight: 500;
|
||||
text-align: center;
|
||||
|
||||
border: 1px solid var(--sl-color-gray-5);
|
||||
background-color: transparent;
|
||||
color: var(--sl-color-text);
|
||||
border-radius: 6px;
|
||||
cursor: pointer;
|
||||
|
||||
transform: translateY(0);
|
||||
transition: all 0.2s ease-in-out;
|
||||
}
|
||||
|
||||
.version-btn:hover {
|
||||
transform: translateY(-2px);
|
||||
box-shadow: 0 4px 8px rgba(0, 0, 0, 0.1);
|
||||
border-color: var(--sl-color-accent);
|
||||
}
|
||||
|
||||
.version-btn.active {
|
||||
background-color: var(--sl-color-accent);
|
||||
color: var(--sl-color-text-invert);
|
||||
border-color: var(--sl-color-accent);
|
||||
font-weight: 700;
|
||||
box-shadow: 0 2px 4px rgba(0, 118, 255, 0.3);
|
||||
transform: translateY(-1px);
|
||||
}
|
||||
|
||||
[data-theme='dark'] .version-btn.active {
|
||||
background-color: #b3c7ff;
|
||||
color: #17264f;
|
||||
border-color: #b3c7ff;
|
||||
box-shadow: 0 2px 6px rgba(179, 199, 255, 0.2);
|
||||
}
|
||||
Reference in New Issue
Block a user